QRI platform architecture

Connect the quality context. Keep authority controlled.

QRI is designed to assemble the permitted evidence around an investigation from the systems where it already lives, preserve exact source and receipt lineage, and expose that context to people, software, and agents through the same controlled application boundary.

Explore QRI
Four distinct boundaries

Ontology, integration, APIs, and agents solve different problems.

Platform direction

Quality Context

A closed quality-specific model over exact source cases, reports, facts, evidence, RCA conclusions, document revisions, suppliers, actions, and effectiveness checks. It is not a generic ontology product or a second source of truth.

Existing foundation

Governed connectors

Durable synchronization and writeback retain source ownership, mapping versions, capture receipts, retries, explicit unknown outcomes, and reconciliation. Connectors—not MCP—remain the integration plane.

Contract-first direction

REST, OpenAPI, events and SDKs

Ordinary applications integrate through versioned application contracts. Public APIs expose typed product capabilities without giving external systems direct database or authority access.

Qualification-gated

Scoped MCP access edge

MCP is intended for permission-filtered reads and immutable proposals after a customer names a real agent workflow. It never replaces connectors, queries PostgreSQL directly, or exposes model-controlled approval, closure, waiver, effectiveness acceptance, or external dispatch.

Quality Context v1

A report-centered context—not Palantir for everything.

The first context is intentionally narrow. It references existing authoritative subjects and exact versions instead of copying business records into a new graph database.

Source caseQuality reportField factEvidence artifactRCA conclusionHistorical caseDocument revisionSupplier versionCorrective actionEffectiveness check
Governed relationships

Every useful relationship carries provenance.

A relationship must retain exact endpoint identity, source event or receipt, mapping version, visibility scope, assertion class, and human disposition. AI proposals cannot silently become authoritative relations.

Derived from
Evidenced by
Cites
Supports
Contradicts
Compared with
Controlled by
Supplied by
Requires action
Verified by

PostgreSQL remains the sole authority boundary.

Connectors, model providers, retrieval services, document processors, SDKs, and MCP processes receive only scoped inputs and capabilities. They do not receive authoritative database credentials and cannot approve, sign, close, waive, release, accept effectiveness, or dispatch external actions.