Institutional systems
Operational records
AI logs, approved policies, case and approval records, identity context, and execution receipts.
Security & deployment
From institutional systems to independently reviewable evidence.
QAi is architected beside the AI-assisted workflow. It brings together the records required for assurance, evaluates each case against the authority that applied, and returns findings and evidence to accountable teams—while the institution’s operational systems continue to govern and execute.
Out-of-band operation · bounded source access · independent verification
OPERATING MODELINSTITUTION → QAi → REVIEW
Controlled integration
Bounded intake
Agreed read-only interfaces or institution-produced extracts, mapped to the workflow and evidence question.
QAi evidence core
Deterministic evaluation
Authority reconstruction, evidence coverage, version-aware checks, case correlation, and explicit findings.
Accountable review
Reviewable outputs
Case records, evidence packs, declared gaps, deviations, and the basis for independent examination.
Operational boundaryThe live workflow remains independent of QAi availability.
The evidence flow
Five steps · one accountable record
Follow the decision from source event to review room.
The integration edge is specific to the institution. The evidence semantics and evaluation discipline remain consistent across workflows.
Scope
Name the consequential workflow, the decision under review, its authority owner, and the evidence question.
Connect
Agree the source systems, access method, required records, and the operational boundary for each connection.
Map
Align institutional identifiers, event times, authority versions, approval roles, and execution events to one case.
Evaluate
Resolve what was known at the time, assess completeness first, then apply deterministic controls to the available record.
Review
Deliver the finding, underlying records, declared gaps, and an evidence pack whose integrity can be checked independently.
Layer 1
Architectural commitments
Security begins with where QAi sits—and what it is permitted to do.
Out-of-path operation, findings rather than commands, distinct evidence records, deterministic evaluation, tamper detection, and independent verification define the product boundary across deployment models.
Operational independence
QAi sits beside the live workflow. The institution’s own systems continue to recommend, decide, approve, and execute independently of QAi availability.
Bounded source access
Each workflow begins with an explicit source map: which records are needed, how they are supplied, what each source owns, and what becomes unresolved when a record is absent.
Institutional decision locus
Named human decisions remain in the institution’s case or workflow system and are ingested as evidence with role, decision, and time preserved.
Coverage before conclusion
Evidence completeness is assessed before controls. Missing records remain visible and prevent an incomplete case from being reported as a definitive result.
Versioned, time-aware records
Authority, policies, controls, actions, and decisions retain their versions and relevant times so reviewers can reconstruct what applied at the moment of action.
Independent integrity checks
Canonical records, SHA-256 member digests, an ordered manifest, and published verification steps let a reviewer check an exported pack outside the producing interface.
Evidence that can leave the platform
Integrity remains reviewable outside QAi.
An exported evidence pack carries the records, declared gaps, canonicalisation method, member digests, manifest digest, and the steps required to recompute them. The reviewer does not need to trust the interface that produced the pack.
Precise assurance boundary. Integrity verification establishes whether the exported objects still match the captured pack. Source completeness, accuracy, lawful basis, and legal sufficiency remain separate review questions.
01Canonical recordsDeclared serialisation rules travel with the pack.
02Member digestsSHA-256 digest for each included record.
03Ordered manifestOne pack digest covers the ordered member set.
04Offline verificationPublished steps support independent recomputation.
Layer 2
Institutional deployment configuration
The operating model is agreed for the institution’s environment.
Source access, hosting model, identity, encryption, residency, retention, isolation, and operational controls are made explicit before representative records are connected.
Decide what remains at source
Identify which original records remain in institutional systems, which references or extracts enter the evidence layer, and what becomes unresolved when a source is unavailable.
Define what must remain traceable
Agree the case references, versions, control identifiers, reason codes, states, and lifecycle events needed to reconstruct the evaluation.
Separate access from evaluation
Set where identifiers, amounts, or source payloads are held, who can access them, and how they remain distinct from the evaluation journal.
Make the evidence consequence explicit
Set retention and deletion rules and record how authorised erasure changes what can still be independently verified later.
Due-diligence operating profile
Nine decisions make responsibility explicit.
The production operating model is recorded as part of institutional onboarding so architecture, security, privacy, operational resilience, and assurance reviewers examine the same agreed boundary.
Configuration, not assumption Hosting, storage, tenancy, identity, encryption, residency, retention, support access, and operational controls are stated for the selected deployment model and supported by the corresponding implementation evidence.
01Source access
02Hosting and responsibility model
03Identity and access control
04Encryption and key ownership
05Data residency
06Retention, backup, and deletion
07Tenant and workload isolation
08Support and diagnostic access
09Incident, audit, and exit controls
Owns the operating environment
Defines approved sources, access, identity, policy, retention, incident responsibilities, and the systems that decide and execute.
Establishes the evidence layer
Configures the case and authority map, applies the evidence discipline, produces findings, and supplies verification material.
Assess the wider context
Determine applicability, legal sufficiency, assurance reliance, and the institution’s third-party and operational-risk treatment.
Start with one workflow
Bring your architecture, security, and evidence questions into the first conversation.
We will identify the source boundary, operational responsibilities, deployment profile, and review outputs required for one consequential workflow.