Governance infrastructure for AI in high-stakes domains.
Two products. One architectural fingerprint. Typed authority. Refusable gates. Persistent lineage. Deterministic floor.
Section 1 · The pattern
Typed authority. Refusable gates. Persistent lineage. Deterministic floor.
The architectural fingerprint has five canonical slots: typed authority decision → pre-call policy gate (refusable) → action execution → post-call enforcement gate (refusable) → outcome record (persistent, lineage-linked). Beneath: deterministic governors that downstream services cannot override.
The five slots
- AuthorityTyped decision; records what was decided before knowing what returns
- Policy gatePre-call evaluation; refusable; typed refusal records
- ActionExecution proceeds (or doesn't)
- Enforcement gatePost-call evaluation; refusable; typed enforcement records
- OutcomePersistent record with foreign-key lineage back to the decision
This pattern is domain-agnostic. It is not specific to civic discourse, governed outbound, or any other concrete use case. It is the substrate-architectural shape any custodial, accountability-oriented, governance-substantive system instantiates.
A proposed third product is evaluated against this fingerprint. If it does not fit, we do not build it.
Section 2 · The instances
The same five slots. Aura, instantiated. Orchestrate, instantiated. Both substrate-citable.
Every slot in the architectural fingerprint maps to specific service classes and schema models in both product backends. The mapping is grep-verifiable.
Two products, one fingerprint
Aura's authority slot is the InstitutionSpeechMode + AccountabilityTag typed pair. Orchestrate's is AiDecisionGatewayService.decide(). Aura's policy gate is AiGovernancePolicyService.evaluate() in aura-backend. Orchestrate's is the same service class in orchestrate_backend. Aura's outcome is InstitutionPost with typed pointers (resolvesInstitutionPostId, continuesInstitutionPostId). Orchestrate's is AiDecisionOutcome with foreign-key lineage. Every row in the fingerprint table renders in both backends.
Two products are not a portfolio. They are evidence that the substrate is architectural, not domain-specific.
Section 3 · AI under custody
Single seam. Pre-call policy. Post-call enforcement. AI cannot override the floor.
AI in production is custodial, not productive. The capability is a vendor question. The custody is the substrate question. The firms that build typed custody substrate own the moat.
Custody is structural
The AI provider is one named external service. Backend-wide grep for import OpenAI returns exactly one match per product. The orchestrator is the only path. Pre-call policy evaluates. Post-call enforcement evaluates again — at two call sites, for defense in depth. Every decision persists with lineage. Audit log: metadata only — never credentials, never message bodies.
Nine typed statuses
ALLOWED AUDIT_ONLY
HUMAN_REVIEW_REQUIRED
BLOCKED EXPIRED NOT_FOUND ENTITY_MISMATCH POLICY_BLOCKED TRUST_BLOCKED
Six of nine enforcement statuses are refusals. The substrate's first-class outcome class is refused.
orchestrate_backend/src/ai/governance/ + aura-backend/src/ai/governance/ + AiEnforcementRecord (9 statuses, schema.prisma)
Section 4 · Refused categories
What we are not.
Each of these category names carries marketing assumptions the substrate refuses. The refusals preserve the substrate's integrity. The substrate is the category-collapser.
Not a CRM.
CRM treats outbound as conversion. Orchestrate treats outbound as refusable governance. Conversion as substrate fails the regulated-sector procurement event.
Not an AI SDR.
AI SDR framing positions AI as a producer. Orchestrate positions AI as a custodial function bounded by typed gates. The AI does not decide to send. The substrate does.
Not sequence software.
Sequence software optimizes for cadence. Orchestrate optimizes for per-send substantive substrate. The categories are perpendicular.
Not a social network.
Social networks optimize for engagement-of-feed. Aura optimizes for continuity-of-record. Engagement substrate is incompatible with civic accountability substrate.
Not a verified-identity Twitter.
Verification is one property of the substrate, not the central differentiation. The institutional voice rendering, typed accountability, typed pointers, and deterministic aggregation are the substantive distinction.
Not an AI safety platform.
AI safety orients around model alignment and pre-deployment behavior. We orchestrate models inside custody during production deployment. The work is complementary; the category is not ours.
Section 5 · Substrate moat
The fingerprint is shared. The substrate is the moat.
Capability is a vendor problem; every six months a new model release shifts the frontier. Governance is a substrate problem; the firms that build typed custody substrate own a moat that compounds with every procurement event.
Each substrate-paying customer hardens the substrate. Each architecture-canon publication strengthens the institutional position. The moat accrues over time. It does not erode when the next model ships — the substrate is provider-agnostic.
Capability translates. Governance compounds.
In ten years, when AI deployment in high-stakes domains is governed substrate-up, the substrate firms — the ones that built the typed authority, the refusable gates, the persistent lineage, the deterministic governors — will be the substrate every regulated-sector AI deployment rests on.
Section 6 · Two products, one substrate
Two domains. One conviction.
The architectural fingerprint instantiates naturally in two domains. Read each substantively.
Aura
Verified-identity civic discourse
Typed accountability. Three speech modes. Typed pointers for resolution and continuation. Open commitments compute deterministically. The audit is the platform.
Read the Aura canonOrchestrate
Governed managed-outbound execution
Nine ordered blocker layers. Seven dispatch decisions; five do not send. Eight rationale questions persist on every decision. Risk only escalates; never relaxes. Refusal is the substrate.
Read the Orchestrate canonFounder
Substrate-architect-led, patient, institutional.
The founder writes the architecture canon openly because the substrate has to be legible to substantive reviewers. The canon is the answer. Writing it is part of the work.