The Platform
Standards as Code
Standards encoded as version-controlled rule packs by program area. Semantic versioning, priority-based composition, conflict detection at load time, machine-readable provenance on every rule.
Standards as Code
The Standards for Accreditation are published as PDFs. They are read by humans, interpreted by humans, and applied by humans, with all the inconsistency that implies. Two quality coordinators reading the same clause produce two slightly different interpretations. Those interpretations live in spreadsheets, in institutional memory, and in the notes of whoever attended the last surveyor training.
Regain Accreditation treats Standards differently. Every requirement is encoded as a machine-readable, version-controlled, deterministically evaluable rule. The Standard is not a document to be interpreted at the moment of evaluation. It is configuration the engine reads.
Fixed engine, swappable rule packs
The compliance engine is a fixed evaluation runtime. Rule packs are swappable configurations that declare what gets evaluated and how.
The separation is architecturally fundamental. When a new accreditation framework needs support, or when an existing framework updates its Standards, the change is a new rule-pack release. The engine does not need to be modified, retested, or redeployed. A new pack is authored, validated, loaded, and evaluated.
Rule packs are organized by program area. A program area's pack declares the conditions to evaluate, the clauses each condition implements, the scoring model the framework uses, and the provenance of each rule.
Pack composition
Rule packs are not evaluated in isolation. They compose, and the composition rules are explicit and enforced:
Core safety pack (always loaded, highest priority). Schema validation, staleness checks, safe-mode enforcement, anti-hallucination invariants. These rules cannot be overridden by any other pack. They are non-negotiable safety invariants.
Domain packs (per clinical area). Contraindications, guideline-derived rules, clinical-practice requirements. These carry the clinical specificity each program area's Standards demand.
Site protocol packs (per facility). Formulary restrictions, escalation procedures, scope-of-practice definitions. These capture the institutional policies the cycle evaluates alongside the published Standards. Site packs can add restrictions; they cannot weaken the layers above them.
Governance packs. Control-plane configuration for operational policy.
Packs are merged, sorted by priority, and evaluated with first-match-wins semantics. If a core safety rule and a site rule address the same condition, the core safety rule wins. Always, automatically, without human intervention.
Conflict detection at load time. The pack loader does not silently resolve conflicts. It detects them, reports them, and rejects any site rule that attempts to weaken a higher-priority safety or society rule. The constraint is enforced programmatically, not by policy, not by review process, but by the loader itself.
Provenance on every rule
Every rule carries a machine-readable provenance record. Fields include:
- Source type: the category of authoritative source the rule traces to
- Source layer: position in the clinical-grounding hierarchy
- Citation: the specific section of the authoritative source
- Source URL: direct link to the published source
- Evidence grade: level of evidence supporting the rule
- Jurisdiction: geographic applicability
- Clinical domain: the program area or specialty
- Approved by: named clinical reviewer who authorized the rule
- Effective date: when the rule became active
- Review interval: how often the rule must be re-validated
- Review due date: the next scheduled review
Every rule is traceable from the finding it produces back through the rule that fired, to the clause it implements, to the published source that authorizes it.
The provenance schema is unified across the substrate, the same shape appears in the supervisory layer, the compliance evaluator, and the governance module. A single provenance query traces a finding from the source observation that triggered it to the published source that authorizes the rule.
Versioning
Every rule pack uses semantic versioning. Every evaluation response carries a composite version string identifying exactly which versions of which packs were applied. This means any historical evaluation can be reproduced, same data, same pack versions, same finding.
When a standards-issuing body revises its requirements, the corresponding rule pack is versioned, and the prior version remains available. Programs transitioning between editions can evaluate against both simultaneously and see exactly what changes, at the clause level, at the metric level, at the source-record level.
Source registry
The substrate maintains a registry of the authoritative sources the rule packs cite, society standards, regulatory documents, institutional policies, with automated review tracking:
- Overdue reviews flagged when a source has not been re-validated on schedule
- Upcoming reviews surfaced before they become overdue
- Orphaned citations detected when a rule references a source that has been superseded
- Validation reports generated for governance review
This is how a living compliance substrate stays living. The Standards evolve. The rules evolve with them. The registry makes sure nothing falls through.