Trust
Accreditation infrastructure earns trust the way regulated systems do, through architectural choices that survive a security review, a clinical operations review, and a peer reviewer's read-through without breaking. The engine is deterministic. The supervision layer is structurally independent from the reasoning layer. Derived evidence observations are hashed before evaluation. Findings cite their sources. PHI and PII are engineered apart.
An example
A compliance finding begins at a clause in a published Standard, encoded as a versioned rule. The rule does not depend on a model's mood. The same inputs produce the same outputs. A regulatory determination cannot be a sample from a distribution, so no large language model sits in the compliance path. The engine is deterministic. The Standards are the configuration.
Evidence enters the engine as structured records pulled from the facility's clinical systems, procedures, reports, credentials, equipment logs. The engine derives evidence observations from those records and hashes them before evaluation, so modification, substitution, or quiet drift in the evaluated dataset is detectable against the hash. The metric the rule reads is a computation over those derived observations, a count, a rate, a coverage figure, not a screenshot of a dashboard. The metric is what the finding cites; the underlying records remain auditable in the source system.
Same inputs, same finding.
When the engine emits a finding, it emits four references with it: the clause in the Standard, the version of the rule that evaluated it, the facility-level metric the engine computed, and the dataset window the metric was computed over. The derived evidence observations behind the metric are hashed; the underlying source records remain auditable in the facility's clinical systems. The public traceability key is clause and metric, not a record identifier. A reviewer who disagrees can read the finding back to any of those four points. Nothing is implicit.
The audit trail is the work product. A peer reviewer can replay the rule against the same clause and the same dataset window and reach the same finding. A facility can see exactly which metric the finding rests on and how it was computed. A security review can confirm who read what and when. The trust model is the audit trail, not the badge above it, not the brand around it, not a promise that something happened correctly somewhere upstream.
The trust model is the audit trail.
Engineering facts
Compliance evaluation
0
No large language model participates in compliance evaluation. Identical inputs produce identical findings. A regulatory determination cannot be a sample from a distribution.1
Per-record integrity
SHA-256
Derived evidence observations are hashed before the engine evaluates them. Modification, substitution, or quiet drift in the evaluated dataset is detectable against the hash.2
Architectural separation
2
Reasoning and supervision run as separate codebases on separate runtimes with separate access controls. They communicate through a single published message contract. The supervision layer can be inspected, replaced, or audited without touching the reasoning layer.3
Four commitments
Each commitment is verifiable against the codebase, not the marketing copy. The four together compose the trust model. None of them is a roadmap promise.
01
Compliance evaluation runs as a deterministic function of the rule pack version and the input records. No large language model is involved at any step of the compliance path. A finding is reproducible from rule pack version + record hash set + engine binary.
02
The reasoning layer and the supervision layer are separate codebases on separate runtimes with separate access controls. They communicate through a single message contract. The supervision layer cannot be silently bypassed by the reasoning layer; bypass requires a change to the contract, recorded in version control and auditable from the audit trail.
03
Derived evidence observations are hashed with SHA-256 before the engine evaluates them. The hash sits in the audit trail next to the finding that used it. A reviewer can confirm the dataset the finding rests on has not changed between evaluation and review. Underlying source records remain auditable in the facility's clinical systems where available.
04
Each finding cites the Standard's clause, the rule version that evaluated it, the facility-level metric the engine computed, and the dataset window the metric was computed over. The audit trail also records who accessed what and when. A finding without that lineage does not ship.
Reviewer trust
Modality-level accreditation runs on peer review. Reviewers read sampled cases and weigh them against the standard of care the societies have agreed to. That work requires clinical judgment, and clinical judgment is the part the substrate explicitly does not try to do.
What the substrate does is take the mechanical work off the reviewer's desk: counting, cross-checking, and aggregating the records that already exist in the facility's clinical systems. The substrate carries that work; the reviewer's time goes to judgment.
A
The substrate automates evidence collection and completeness checks against the rule pack for that program area. A reviewer opens an application that is already complete on the mechanical dimensions, or sees the precise gaps named.
B
Case studies arrive at the reviewer with the underlying records, the rule version that referenced them, and the metric that flagged them for sampling. The reviewer judges the clinical content; the substrate explains how the sample was selected.
C
A reviewer who disagrees with a finding writes the disagreement back into the same audit trail the finding lives in. Override patterns become evidence in their own right, input to the societies that refine the Standards, not a workaround the substrate hides.
D
Accreditation decisions remain the work of the accrediting body and its reviewers. The substrate compiles the evidence and explains how it was compiled. The judgment continues to sit with the people the Standards already assign it to.
HIPAA posture
The substrate is building toward HIPAA compliance, that is a compliance posture earned over time against a specific covered workload, not a claim a vendor gets to make in advance. What is in place today is the architectural separation the standard expects: a designated boundary between protected health information and personally identifiable information, with the supervision layer engineered to operate without seeing PHI directly.
01
PHI is treated as a distinct class of record with its own storage boundary, its own access controls, and its own audit-trail entries. PII is treated separately. Mixing the two requires an explicit, logged crossing.
02
The supervision layer reads structured findings and record hashes through a published message contract. It does not receive PHI payloads. A supervision review can reach a verdict without ever holding the patient-identifying content the verdict refers to.
03
Role-based access control governs the external API surface. Read scopes are minimal by default. Access events are written to the audit trail alongside the findings they relate to, so a security review can answer who-read-what against the same record set the compliance review reads.
04
The roadmap to full HIPAA compliance is staged against the three safeguard categories the standard names. Status is tracked openly against the controls the substrate already enforces and the ones still ahead.
Open where it matters
The message contract between the reasoning layer and the supervision layer is the interface a third party would need to audit, replace, or inspect the supervision layer independently. That contract, the protocol, not the implementations on either side, is planned for open-source release under Apache 2.0. It is not yet public; the work sits in private repositories while the contract stabilises. The rule packs encoded against published Standards remain tied to the standards bodies that own them.
The depth, the rule-pack composition, the evaluation engine, the reviewer-facing tooling, stays proprietary. That is the work, and the work is what funds the substrate. The point of opening the contract is that, once the release lands, a customer or auditor will have the technical means to inspect the supervision layer independently, and the architectural option to replace it with an alternative implementation that speaks the same contract.
The thesis
Can a peer reviewer reproduce the same finding from the same clause and the same facility-level metric? Can a security review confirm who accessed what and when? Can the facility see exactly which metric the finding rests on and how it was computed? Can the supervision layer be audited without asking the reasoning layer for permission? Each question is a test the architecture must pass, and each answer is in the codebase, not the marketing copy.
The Standards do not move. The trace catches up.
Figure 3.1, Reproducibility surfaces, decomposed by trust commitment
Figure 4.1
Read more
How the substrate carries the work across the accreditation cycle, eight scenarios drawn from the operational pain of compiling evidence by hand.
Explore Use Cases →Longer-form analysis on the structural forces reshaping accreditation, the visibility gap between cycles, the manual abstraction cost, the override pattern as AI evidence.
Read the Insights →A Delaware C-Corporation building clinical AI infrastructure for healthcare accreditation. Self-funded. Field experience deploying clinical systems at medical centers in Central Asia.
Read about Regain →We will trace any compliance finding from clause to rule version to the facility-level metric the engine computed, and answer security-review questions against the architecture, not the brochure.
Request a walkthroughFootnotes
