Document control — every version retained, exactly one version approved

A version is a record, not a field that gets overwritten

A document code identifies a family — SOP-1042 — and each version of it is its own record with its own file, content type, size, and storage path, unique on code plus version. Creating a new version finds the highest existing version, writes a new record one above it in Draft with its own uploaded file, and inherits the type, name, and description of its predecessor unless you change them. The previous version is still there, still downloadable, still exactly the bytes that were uploaded. The document page lists the full version history with each version's status.

Document types are fixed rather than user-invented: SOP, Drawing, Certificate, Specification, Work Instruction Attachment, and Other.

Sequenced approval with automatic supersession

Submitting a Draft moves it to Pending Approval. Approvals are a sequenced chain, and each approval takes the lowest-numbered step still pending, stamping it with the approver's identity, the timestamp, and their comments. A document submitted without a pre-seeded chain gets a single default step at the Supervisor role rather than becoming approvable by nobody.

When the last step in the chain approves, two things happen together: the document becomes Approved, and every other approved version of that same code is set to Superseded. Exactly one version of a document code is approved at any moment. That is the control ISO 13485 §4.2.4 is actually asking for when it requires preventing the unintended use of obsolete documents — not a naming convention, an enforced state.

Draft-only editing, no deleting approved records

A document can only be edited while it is a Draft — its name, description, and effective and expiry dates all freeze once it enters approval. An approved document cannot be deleted at all; the API refuses the request. Withdrawing an approved revision from use is done by approving its successor, which supersedes it. Deleting a document that is not approved removes its stored file along with its links and approval steps, so a deletion does not leave orphaned blobs behind.

Effective and expiry dating

Each version carries an optional effective date — null means effective on approval — and an optional expiry date. Both are set at creation or on a new version, filterable, and indexed. The dates are not decoration: the retrieval indexer honors them, holding back a document whose effective date is in the future and withdrawing one that has expired.

Linked to the thing it controls, at the version in use

A document link attaches a document to any entity in the system — a piece of equipment, a work instruction — and the link resolves to a specific version, not to the family. Links are indexed in both directions, so "which controlled documents apply to this machine" and "where is this drawing used" are both single queries. When the drawing is revised, the old link still points at the revision that was in force, which is what a genealogy question needs a year later.

Where files actually live

Files are never stored in the database. Production deployments write to Azure Blob Storage under a tenant-partitioned path; the domain model holds only an opaque storage path resolved by a storage service, so the same code runs against a local filesystem in development. Uploads go through an authenticated REST endpoint with a 100 MB limit, and downloads return the file byte-identical to what was uploaded.

Audit trail and tenant isolation

Every create, modify, and delete on a document and on an approval step is written to the tamper-evident audit trail automatically, at the persistence layer, with per-property before and after values, the acting user, and the timestamp. It is not something a service method has to remember to call, which is why no code path can forget it. Documents are tenant-scoped twice over: an application-level query filter and a PostgreSQL row-level security policy on the table itself. Authoring, approval, rejection, and linking are restricted to Admin, Platform Admin, and Supervisor roles.

Retrieval over your own documents

With the AI Analytics add-on enabled, approved documents are indexed for retrieval so the copilot can answer from your SOPs and specifications rather than from generic knowledge. What ships, specifically:

• Only approved, currently-effective documents are indexed. A future-effective document is held back; an expired one has its chunks removed.
• Superseding a revision retires it from retrieval. Chunks for superseded and archived documents are purged, so last year's revision stops answering this year's questions.
• Citations carry the version. Every retrieved passage returns the document code, name, type, and version number alongside its relevance score — a citation you can go and check.
• Every retrieval is logged to the AI interaction trail, because an AI answer that contributes to a regulated record has to be reconstructable.
• Mechanics, for the technical evaluator: text is split on paragraph, line, and sentence boundaries into chunks of roughly 1,000 characters with 200 characters of overlap, embedded through the configured provider (OpenAI's text-embedding-3-small at 1,536 dimensions by default — see our sub-processor register), and retrieved by cosine similarity in PostgreSQL, returning the top five passages above a 0.7 relevance floor. Indexing runs on a 15-minute cycle and does not run at all unless the add-on is configured.

One constraint to be blunt about: text extraction covers text, JSON, XML, and HTML uploads. A PDF, an Office file, or a scanned drawing is indexed by its metadata — code, version, type, description, filename — and not by its contents. There is no PDF text extraction and no OCR today. If retrieval over PDF SOP content is a requirement for you, raise it in the demo; do not assume it from the word "retrieval."

Regulatory mapping

Qontiv is designed for compatibility with these standards and produces the document-control records an auditor asks for. Qontiv itself is not certified to any of them — your certification body audits you.

Scope — what this is not

• Approval is identity-stamped and audit-logged, not a §11.50 electronic signature. Each approval records who approved, when, and their comments, on the tamper-evident audit trail. It is not currently bound to an electronic signature with a declared meaning the way a PPAP warrant, a CAPA closure, or an APQP gate is. If a signed document-approval record is a hard requirement in your validation plan, raise it before you scope.
• No controlled-copy watermarking or print control. There is no copy numbering, no "uncontrolled if printed" stamp applied at download, and no view-only rendering. Downloads are the original file.
• No document-management-system connector. There is no SharePoint, Documentum, OpenText, Box, or M-Files integration. Documents are uploaded to Qontiv through the UI or the REST endpoint.
• Multi-step approval chains are a configuration exercise, not a UI one. The data model supports a sequenced chain of any length, but there is no API today for composing one on screen — a document submitted without a pre-seeded chain gets the single default step.

Availability

Document management and the approval workflow are included in Professional. Retrieval over your own documents is part of the separately priced AI Analytics add-on, which is purchasable on any plan including Core. See pricing, orrequest a demo to bring one of your own SOPs and walk it from draft to approved.