Security & compliance

The full statements behind the four answers

The home page answers four questions in a paragraph each. This page is the version a compliance or procurement team reads before a call: the same answers, at the length the question actually deserves, with the artefacts named.

Where does our data go, and where does it live?

Nowhere outside your infrastructure. Under Ferro, inference, indexing and record writing all run inside your boundary, so documents and prompts never transit a vendor network. Residency is therefore whatever your own hosting is: we cannot move your data to another region because we never hold it. There is no vendor-side inference, no training on your data, and no third-party subprocessor in the decision path — which is a statement about architecture, not about a contract clause.

• Inbound: read-only connectors to your warehouse, document store and case system, authenticated with credentials you issue and can revoke.
• Internal: the evidence index and the model both sit on the runtime host. Traffic between them does not leave it.
• Outbound: none from the decision path. The runtime does not phone home, does not report telemetry and does not fetch updates in the air-gapped topology.

Network diagram and data-flow register

What is the tenancy and isolation model?

Single-tenant by construction. There is no shared plane to isolate you within, because the deployment is yours: your host, your model store, your index, your database. Multiple environments inside one customer — development, staging, production — are separate runtimes with separate indexes and separate model stores, not namespaces inside one process. An index built from production documents cannot be reached from a staging runtime, because it is on a different host.

• No shared inference pool, no shared vector store, no cross-customer cache.
• Environment separation is physical or virtual-machine level, never logical.
• Credentials are per-environment; a staging connector cannot read production sources.

Deployment topology and environment separation statement

What is in the decision record, and can it be altered?

Every recommendation writes one record: the sources cited, the weight given to each, the confidence figure, the conditions that would reverse it, the model build, the index generation, the reviewer who accepted or overrode it, their stated reason, and the timestamp. Records are append-only and hash-chained — each one carries the hash of its predecessor, so removing or editing a record breaks the chain at every record after it. Export is signed PDF or JSON.

• Append-only: corrections are new records that supersede, never edits in place.
• Hash-chained: integrity is verifiable by anyone holding the chain, including you, without our participation.
• The record is written by a process separate from inference, so a failed inference still produces a record saying so.

Signed decision record, PDF and JSON, with chain verification tool

How long is anything kept, and what happens on deletion?

You decide, because the storage is yours. Quorum ships a default of seven years for decision records, which is the common regulatory floor in the sectors it serves, and the default is a configuration value rather than a product constraint. Deleting a source document does not delete the records that cited it: the record keeps the citation and its content hash, and marks the source unavailable. That is deliberate and it is a trade-off worth stating — a decision record that silently loses its evidence is worse than one that says the evidence is gone.

• Records: default seven years, configurable, stored in your database under your own retention tooling.
• Evidence index: rebuilt from sources; deleting a source removes it from the index at the next incremental build.
• Deletion requests: a record can be tombstoned — its content removed, its hash and chain position kept — so the chain still verifies.

Retention schedule and tombstone procedure

Who can see what, and what is logged?

Access control is role-based and resolved against your own identity provider over OIDC — Quorum does not maintain a user directory, and there is no vendor account with access to a customer deployment. Four roles ship by default: reviewer, approver, auditor and administrator. Every read of a decision record is logged with the principal, the record and the time, because in an adverse-action context who looked at a decision is itself auditable information.

• Authentication: your identity provider, OIDC. No local passwords.
• Authorisation: reviewer sees and acts on decisions in their queue; approver signs; auditor reads everything and changes nothing; administrator configures and cannot sign.
• Audit log: reads as well as writes, append-only, same chain guarantee as the record.

Role matrix and audit log schema

What happens when a reviewer disagrees with Quorum?

They override it, and the override is the interesting record. Quorum never issues a decision — a named human accepts, overrides or escalates every recommendation, and the record stores which, with the reason text. Overrides are not exceptions to be suppressed: they are the signal that the evidence weighting is wrong, and they feed the next evidence review. There is no confidence threshold above which Quorum acts alone, and no configuration that removes the human step.

• Every recommendation lists the conditions that would reverse it, so a reviewer can test the weakest link before signing rather than after.
• Override reasons are structured and free-text, and both are retained.
• Override rate per decision surface is reported; a rising rate is treated as a defect in the weighting, not as reviewer error.

Override log and reviewer attestation format

Who are your subprocessors?

None in the decision path, under Ferro. Inference, indexing and logging run inside your boundary, so there is no processor to name, review or flow down obligations to. If you choose to run Quorum against a hosted model instead of Ferro, that model provider becomes a subprocessor you must disclose and review, and the decision to accept that is yours rather than a default we set. Our corporate systems — the ones that hold your contract and our support correspondence — have their own subprocessors, and that list is separate and published.

• Decision path under Ferro: no subprocessor.
• Decision path with a hosted model: that provider, disclosed by you.
• Corporate systems: listed separately; they never touch a decision.

Subprocessor register, decision path and corporate, listed separately

How does this map to the EU AI Act, and what stays ours?

Quorum supplies the evidence: logging, human-oversight records and transparency artefacts. It does not supply a classification and it cannot supply a conformity assessment — those remain yours, and no vendor can certify you. The distinction matters commercially: a supplier claiming to make you compliant is describing something the Regulation does not permit them to do.

• Ours to supply: decision records, human-oversight evidence, transparency artefacts, model build and index provenance.
• Yours to do: classify the system, run the conformity assessment, register where required, and hold the residual risk.

Obligation timeline mapped to your deployment date

The obligation timeline in full

Absolute dates only. Verified against Regulation (EU) 2024/1689 as amended by the Digital Omnibus, Regulation (EU) 2026/1744.

Artefacts we send before a call

Requested by name, sent under NDA, and prepared for this deployment rather than pulled from a folder. Nothing on this list is a brochure.

• Network diagram and data-flow register
• Deployment topology and environment separation statement
• Signed decision record, PDF and JSON, with chain verification tool
• Retention schedule and tombstone procedure
• Role matrix and audit log schema
• Override log and reviewer attestation format
• Subprocessor register, decision path and corporate, listed separately
• Obligation timeline mapped to your deployment date