Know · make knowledge usable
Nex Knowledge Base
On-premises Knowledge search and Q&A
Structure-aware chunking, dual-path retrieval, RRF fusion and reranker re-ranking, all completed on-premises.
Home Products NexSpec Hub
Product 01 · Source
NexSpec Hub
Specification and document master data hub
Collect specifications, source files, version history and audit records into one authoritative source.
5 levels
Fixed project structure
3 types
Interface languages
300s
Download ticket validity
Problem → Approach
Versions can no longer rely on people to confirm them
The same specification ends up in different versions across testing, requirements, procurement and suppliers — the root cause of such incidents is not people, but the system.
| The old way | The NexSpec Hub approach |
|---|---|
| Files scattered across shared drives, the latest version confirmed by hand | Source files and version history live in the repository, with version numbers, status and timestamps |
| No one can say who changed what, and audits come up empty | SHA-256 verification plus append-only audit records, verifiable one by one |
| Chinese, Japanese and English documents mixed together, each read in isolation | A trilingual interface with multilingual search, storing each document's language independently |
| Once a file is sent out, it cannot be recalled | Five-minute, single-version read-only download tickets that expire the moment they are revoked |
Capabilities
Seven capabilities to replace seven spreadsheets
Bulk upload & deduplication
Files with the same structure and name are automatically appended as revisions, duplicates detected, dates and minor-version suffixes confirmed one by one, with per-item results and retry support.
Version status flow
Draft → pending release → released. After a new version is released, the old version is marked as superseded, and individual revocation is supported.
Non-overwritable source files
Source files are locked on ingestion, verified with SHA-256 and checked for duplicates; a version can only be created once the upload session completes.
Relationships & structure management
Four relationship types — parent / child / reference / related — a one-hop relationship graph, and circular reference blocking; a fixed five-level project structure anchors section placement.
Body extraction & search
Body extraction and snippet viewing for Office documents, text PDFs, TXT and Markdown; hybrid keyword and vector search with optional re-ranking.
Q&A with citations
Ask questions directly against specifications in the repository; answers come with citations you can click through to the source.
Trilingual interface
Simplified Chinese / Japanese / English. Interface copy, statuses, forms and date formats switch with the language.
Download tickets & revocation
Read-only, single-version download tickets valid for five minutes. After revocation, tickets already issued expire immediately.
Interface
Audit trail: who changed what, and when
Releasing, superseding, uploading, parsing, issuing download tickets — every operation leaves a record: operation event, operator, resource identifier and timestamp. Records are appended in a chain and can be verified one by one after the fact.
N
Specification library
Body domain
Bulk upload
Specification libraryBaselinesAudit trail
4,182Audit records
326Release events
1,284Resource identifiers
0Rewritable records
Audit trailLast 30 days
Newest first
Operation eventOperatorResource identifiersTime
Release revision
Yyu-peng
NX-BCM-0141 · v2.4DOMAIN · Body domain
September 21, 202614:32:07
Supersede old version
Yyu-peng
NX-BCM-0141 · v2.3 → v2.4Old version moved to archive
September 21, 202614:32:07
Upload version
Yyu-peng
NX-BCM-0141 · v2.4SHA-256 verification passed
September 21, 202614:30:41
Parse completed
Ssystem
NX-BCM-0141 · v2.4 · NexTest128 atomic requirements
September 21, 202614:35:12
Issue download ticket
Zzhang.h
NX-BCM-0141 · v2.4Valid for 300 seconds
September 22, 202609:12:33
Create specification
Lli.ming
NX-BCM-0141First version v2.2 ingested
July 18, 202616:40:09
Archive specification
Yyu-peng
NX-HMI-0019 · v0.9Status change, file retained
September 17, 202619:53:20
Released files cannot be overwrittenRecordsNot rewritableEach version Independent content fingerprint
Why old versions cannot be deleted
In automotive R&D, what a given revision said at the time is often exactly what accountability and retrospective reviews need. So Hub offers no physical delete interface; archiving only changes status, retaining the file and all its versions together.
- Releasing fixes the baseline. Cross-system references point to a specific version, not to "the latest".
- Revocation takes effect immediately. Once revoked, download tickets already issued are voided as well.
- Records that cannot be altered. Each audit record inherits the hash of the previous one, so any later tampering breaks the chain.
- Files that cannot be overwritten. Released files cannot be overwritten; each version has its own content fingerprint. To change something, upload a new version.
Workflow
Four steps after a specification comes in
01
Ingestion & deduplication
On bulk upload, the system determines merge relationships from structure and name, automatically appends revisions, flags duplicate content and reports the result item by item.
02
Relationships & structural placement
Attach it to the five-level project structure to build parent, child, reference and related links; circular references are blocked by the system.
03
Release & version management
Draft → pending release → released. Releasing fixes the version baseline, and older versions are automatically marked as superseded.
04
Search, Q&A and download
Hybrid search and cited Q&A query the body text stored in the repository directly; when source files are needed, a ticket is issued for a read-only, single-version download within five minutes.
Design Decisions
Three deliberate design trade-offs
Non-overwritable source files
We do not allow uploaded source files to be overwritten. Revisions are appended as new versions, and old versions are kept permanently — because the revision as it stood at the time is often what accountability requires.
No physical delete interface
Archiving only changes status, retaining the file and all versions together. It is not an oversight but a deliberate choice.
Body parsing belongs to NexTest
Hub owns master data and versions, while NexTest accesses them through fixed-version references. Responsibilities are split, and neither side does a half job.
Audit & Security
Auditing needs verifiable evidence, not just logs
The endpoint of version governance is verifiability — and that starts being recorded from the very first second a source file enters the repository.
- SHA-256 verification.Every source file is checksummed on ingestion, giving it a verifiable identity.
- Append-only chained audit.Each audit record inherits the previous record's hash, is verifiable one by one, and cannot be tampered with after the fact.
- Fixed version baselines.Fixed on release: cross-system references point to this revision, not to "the latest".
- Time-limited tickets and revocation.Download tickets expire in five minutes and are read-only for a single version; after revocation, issued tickets expire immediately.
- Transactional outbox and webhook retries.Outbound notifications lose no events, and failures are automatically retried.
Continue
The next link in the chain
Test · turn it into an asset
NexTest Studio
AI test closed-loop platform for automotive software
From specification to test specification and on to the traceability graph, ten Agents run the closed loop together.
Source · Back to the start
Back to home
See how the product line connects into one chain
Document master data → internal knowledge → test closed loop, with one single fact carried all the way through.
Request a Demo
Bring a specification and walk through ingestion to release on the spot
Covering version appending, duplicate detection, relationship building and five-minute ticket downloads.