Platform · Architectural deep-dive

Five guarantees, written into the schema.

This page is for the technical reviewer. Its readers are state Chief Technology Officers, Managed Care Organization (MCO) security leads, and the architecture teams a procurement officer forwards a screenshot to. The five guarantees below are not policy commitments. They are enforced in the database schema and the route layer.

What follows is a guarantee-by-guarantee walk-through with the mechanism category, the enforcement surface, and the public statutory or precedent basis for each. Source citations are available under NDA. Everything else is published on this site.

Schema scope
195+ tables in the compliance schema · structured data model
Trigger surface
27+ Database triggers · append-only enforcement
Test surface
4,100+ Automated tests · CI-gated
Statute coverage
9 / 9 Federal exemption categories · § 71119

Numbers updated

Decision 01

Nothing is ever deleted.

The plain-language form of the first guarantee. The technical name is append-only decision ledger. Every compliance determination is written as a new row in an immutable ledger and is never updated in place. That covers every hour logged, every exemption granted, and every cure-period pause.

The mechanism is a row-level trigger that raises an exception on UPDATE or DELETE attempts against the ledger tables. There is no application-level honor code; the database refuses the operation even if a hypothetical privileged client tried. This is how the audit trail survives a court challenge three years after the fact: the integrity is enforced at the storage layer, not the policy layer.

Mechanism · Storage-layer immutability
Mechanism
Row-level triggers raise exception on UPDATE / DELETE attempts against ledger tables · enforcement at storage, not policy
Surface
27+ such triggers across the schema · refuses operation regardless of caller privilege
Evidentiary
Court-defensible audit chain · integrity preserved across application-layer failure modes
Standard
ACID isolation · append-only ledger pattern

Read the full architectural record at /decisions/append-only-decision-ledger .

Decision 02

Every decision is reproducible.

The plain-language form of the second guarantee. The technical name is deterministic replayability. The same inputs, run against the same versioned rule set, produce the same compliance determination at any point in the future.

Every determination stores the inputs, the rule version, and the deterministic seed. An auditor working in 2030 can replay a 2026 determination and arrive at the same outcome. There is no clock-bound randomness, no "current best estimate" logic, no stale model output. The system was built to be re-audited, not just audited.

Mechanism · Deterministic replayability
Mechanism
Every determination stores inputs · rule version · deterministic seed · canonical inputs hash
Surface
Pattern repeated across 195+ schema declarations · unique replay index per beneficiary + rule version + inputs
Operational
An auditor in 2030 replays a 2026 determination and arrives at the same outcome
Discipline
No clock-bound randomness · no model output · no current-best-estimate logic in determination paths

Read the full architectural record at /decisions/deterministic-replayability .

Decision 03

The platform fails safe.

The plain-language form of the third guarantee. The technical name is fail-closed audit. If authentication fails, access is blocked. If an audit log write fails, the operation rolls back. Nothing proceeds silently. Nothing is ever lost.

The pattern is a transactional wrapper around every state-changing operation: the audit log write and the business mutation share a single database transaction. If the audit write fails, the whole transaction rolls back. There is no path through the codebase where a determination is made but unrecorded, or recorded but unmade. This is enforced in the route layer.

Mechanism · Transactional audit wrapper
Mechanism
Every state-changing operation binds the business mutation and the audit-log write to a single database transaction
Surface
Used by every state-changing route handler · no codepath where a determination is made but unrecorded, or recorded but unmade
Failure mode
Audit-write failure rolls back the business mutation · fail-closed at the route layer
Standard
ACID atomicity

Read the full architectural record at /decisions/fail-closed-audit-transaction .

Decision 04

Viewing and changing are separate.

The plain-language form of the fourth guarantee. The technical name is view / mutation separation. A beneficiary's compliance record cannot be altered as a side-effect of a read.

The codebase enforces this with a typed split at the route layer. Read endpoints can only call read-tagged functions. Write endpoints can only call mutation-tagged functions. There is no shared layer that does both. Silent state changes during view operations are architecturally impossible. The type system refuses to compile code that crosses the boundary.

Mechanism · Type-system route taxonomy
Mechanism
Read endpoints can only call functions tagged readonly · write endpoints can only call functions tagged mutation · no shared layer that does both
Surface
80+ read handlers, all readonly-tagged · boundary spans the entire beneficiary-facing API
Enforcement
Compile-time refusal to build code that crosses the boundary · lint-rule + strict type discipline
Result
Silent state changes during view operations are architecturally impossible · not a policy claim, a build-system one

Read the full architectural record at /decisions/view-mutation-type-separation .

Decision 05

Only defined actions exist.

The plain-language form of the fifth guarantee. The technical name is closed-set actions. The platform operates on the actions and statuses that the statute permits. What can happen is what the statute documents.

The mechanism is an explicit enum of every admissible action and status, modeled as database-layer constraints and type-system discriminated unions. There are no "OTHER," "misc," or open-ended text fields where a future user could type a state the law does not recognize. The 9 federal exemption categories from § 71119 are 9 enum members; there is no 10th.

Mechanism · Statute-bound action enums
Mechanism
Every admissible action and status modeled as database-layer constraints and type-system discriminated unions
Surface
9 / 9 federal exemption categories · 17 / 17 statutory exclusion categories · no OTHER, no misc, no open-ended fields
Enforcement
DB-level CHECK · type-level discriminated union · enum membership rejected at request boundary
Authority
H.R. 1 § 71119 · 42 U.S.C. § 1396a(xx)(7)

Read the full architectural record at /decisions/closed-set-actions .

Audit it yourself

Verifiable by the public.

  • i.
    Sitemap and structured data civitascom.com/sitemap-index.xml · Schema.org Organization JSON-LD on every page · AboutPage schema on /about · TechArticle schema on /platform
  • ii.
    Security disclosure (RFC 9116) civitascom.com/.well-known/security.txt · machine-readable contact, expiration, canonical URL
  • iii.
    LLM-readable site overview civitascom.com/llms.txt · per llmstxt.org spec · structured access for evaluation agents
  • iv.
    Beneficiary safeguards register civitascom.com/safeguards · five code-enforced beneficiary protections with bilateral evidence
security@civitascom.com