Building the Accumulated Context Graph: The Five Governed State Domains, Temporal Validity Controls, and Postgres Implementation Architecture

Why Is Semantic Similarity Structurally Insufficient for Enterprise Autonomy?

The prevailing architecture for enterprise agentic software relies on a dangerous assumption: that retrieval of similar text is equivalent to understanding institutional reality.

When engineering teams build autonomous systems using basic Retrieval-Augmented Generation (RAG) or vector memory buffers, they optimize primarily for semantic relevance. A query is embedded, cosine distance is computed across a vector index, and the top-$k$ text fragments are injected into the agent's prompt window.

In high-consequence enterprise environments (commercial underwriting, clinical healthcare workflows, regulatory compliance, and infrastructure management), semantic retrieval alone is structurally insufficient.

RAG and ACG are not mutually exclusive. In a governed architecture, semantic search serves a specific, bounded discovery role:

RAG discovers candidate context. The Accumulated Context Graph determines what is admissible. Policy and authority determine what is permitted. Execution and outcome records determine what the organization learns next.

Unverified material may be used as a discovery or hypothesis signal, but it must never be treated as governing precedent or authorize a consequential state transition. An ACG does not guarantee recall; it guarantees admissibility.

What Are the Five Governed State Domains in an Accumulated Context Graph?

An enterprise is not a flat collection of documents or a single hierarchical tree. It is a dynamic network of reporting authorities, operating policies, execution logs, approved exceptions, and real-world outcomes.

To govern agent autonomy, an ACG structures persistent institutional context across five governed state domains:

flowchart TD
    subgraph ACG["ACCUMULATED CONTEXT GRAPH (Governed State Domains)"]
        direction TB

        subgraph S1["1. STRUCTURAL STATE (Topology & IAM)"]
            A1["Entities, Account Hierarchies, Roles & Effective Authority Context"]
        end

        subgraph S2["2. EPISODIC & OUTCOME STATE (Execution Ledger)"]
            A2["Append-Only Inferences, Tool Calls, Rollback Logs & Observed Results"]
        end

        subgraph S3["3. PRECEDENT STATE (The Compounding Asset)"]
            A3["Authorized Overrides, Scoped Exceptions & Revalidation Triggers"]
        end

        subgraph S4["4. POLICY STATE (Machine-Executable Rules)"]
            A4["Policy-as-Code Declarations, Hard Limit Invariants & Versioned ASTs"]
        end

        subgraph S5["5. ADJUDICATION STATE (Dispute Workflow)"]
            A5["Escalation Records, Contested Judgments & Committee Workflows"]
        end

        S1 <--> S4
        S2 --> S3
        S4 --> S3
        S3 <--> S5
        S2 -. "Observed Outcomes Validate Precedents" .-> S3
    end

    style ACG fill:#09090b,stroke:#10b981,stroke-width:2px,color:#ffffff
    style S1 fill:#18181b,stroke:#3b82f6,stroke-width:1.5px,color:#ffffff
    style S2 fill:#18181b,stroke:#64748b,stroke-width:1.5px,color:#ffffff
    style S3 fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#ffffff
    style S4 fill:#1e1b4b,stroke:#8b5cf6,stroke-width:1.5px,color:#ffffff
    style S5 fill:#451a03,stroke:#f97316,stroke-width:1.5px,color:#ffffff

1. Structural State (Organizational Topology & Identity)

• What It Stores: The baseline relational model of the enterprise: entities, account hierarchies, customer risk tiers, department structures, and role-based authority ceilings.
• Governance Function: Informs the agent who is who and what effective authority context applies. It prevents a junior analyst from being treated as an authorized policy signer.
• Storage Pattern: Relational tables with foreign-key bindings to enterprise IAM and identity providers.

2. Episodic & Outcome State (Execution & Verification Ledger)

• What It Stores: An append-only log of every inference call, tool mutation, agent proposal, user override, and subsequent observed real-world outcome (e.g., loan repayment history, audit findings, or downstream system errors), alongside rollback and compensating action status.
• Governance Function: Provides forensic traceability and closes the feedback loop by recording whether past decisions succeeded or failed in production.
• Storage Pattern: Append-only event tables with immutable timestamps, run IDs, and mutation snapshots.

3. Precedent State (Governed Overrides & Scoped Exceptions)

• What It Stores: The structured repository of human-authorized exceptions and overrides that have passed through the Classification Gate.
• Governance Function: This is the primary compounding asset of the product. When an authorized supervisor overrides an agent and classifies the correction as a scoped precedent, the system records:
• The exact applicability condition envelope (e.g., "ARR > $500k AND Tenure > 3 years").
• The authorizing role and user ID at the time of creation.
• The temporal validity interval and dynamic revalidation triggers.
• Cohort-controlled outcome metrics across reuses.
• Storage Pattern: Versioned relational tables bound to parent policy revisions and entity scopes.

4. Policy State (Machine-Executable Constraints)

• What It Stores: The formal, machine-readable rules of the enterprise (Policy as Code).
• Governance Function: Defines non-negotiable boundaries, deterministic calculation rules, and statutory regulatory requirements that probabilistic LLMs are forbidden to violate.
• Storage Pattern: Versioned policy registry containing declarative schemas and immutable revision records.

5. Adjudication State (Active Disputes & Committee Resolutions)

• What It Stores: The state of active escalations where an agent's proposal is disputed, where two organizational policies conflict, or where a human override represents an unresolved judgment.
• Governance Function: Manages the lifecycle of decisions requiring multi-stakeholder human sign-off (e.g., Credit Committee reviews, Ethics Board deliberations). Once resolved, the adjudication outcome compiles into a Precedent State node.
• Storage Pattern: State-machine workflow records with audit timestamps and sign-off chains.

What Is the Production PostgreSQL Blueprint for an Accumulated Context Graph?

An ACG can begin in PostgreSQL as the governed transactional system of record, with specialized stores (object stores, event streams, search indexes) added only where telemetry scale or specialized workflows justify them.

Production Relational Schema (PostgreSQL DDL)

-- Enable pgvector extension for candidate precedent discovery
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS vector;

-- ============================================================================
-- 1. STRUCTURAL STATE: Topology, Entities & Authority Boundaries (Layer 1)
-- ============================================================================

CREATE TABLE entities (
    entity_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    external_identifier VARCHAR(128) NOT NULL UNIQUE,
    entity_type VARCHAR(64) NOT NULL,            -- e.g., "commercial_borrower", "healthcare_provider"
    risk_tier VARCHAR(32) NOT NULL DEFAULT 'standard',
    status VARCHAR(32) NOT NULL DEFAULT 'active', -- "active", "suspended", "under_review"
    attributes JSONB NOT NULL DEFAULT '{}'::jsonb,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_entities_type_tier ON entities (entity_type, risk_tier);

-- ============================================================================
-- 2. POLICY STATE: Machine-Executable Rules & Versioned ASTs (Layer 4)
-- ============================================================================

CREATE TABLE policies (
    policy_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name VARCHAR(255) NOT NULL,
    domain VARCHAR(128) NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE policy_revisions (
    policy_revision_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    policy_id UUID NOT NULL REFERENCES policies(policy_id) ON DELETE RESTRICT,
    version VARCHAR(32) NOT NULL,
    rules_schema JSONB NOT NULL,                 -- Machine-executable JSON Schema / AST
    is_active BOOLEAN NOT NULL DEFAULT TRUE,
    effective_from TIMESTAMPTZ NOT NULL,
    effective_until TIMESTAMPTZ,
    approved_by UUID NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT uq_policy_version UNIQUE (policy_id, version)
);

CREATE INDEX idx_policy_revisions_active 
    ON policy_revisions (policy_id, is_active) 
    WHERE is_active = TRUE;

-- ============================================================================
-- 3. PRECEDENT STATE: Governed Overrides & Scoped Exceptions (Layer 3)
-- ============================================================================

CREATE TABLE precedents (
    precedent_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    parent_policy_revision_id UUID NOT NULL REFERENCES policy_revisions(policy_revision_id),
    authorizer_id UUID NOT NULL,
    authorizer_role VARCHAR(128) NOT NULL,
    authorization_tier VARCHAR(64) NOT NULL,
    scope_conditions JSONB NOT NULL,             -- e.g., {"tier": "commercial", "min_dscr": 1.15}
    rule_mutation JSONB NOT NULL,                -- Parameter override permitted by human supervisor
    valid_from TIMESTAMPTZ NOT NULL,
    valid_until TIMESTAMPTZ,                     -- Nullable if strictly governed by review triggers
    next_review_at TIMESTAMPTZ,
    revalidation_trigger VARCHAR(128),           -- e.g., "quarterly_macro_review", "policy_revision_change"
    superseded_by UUID REFERENCES precedents(precedent_id),
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_precedents_temporal 
    ON precedents (valid_from, valid_until, parent_policy_revision_id);

CREATE TABLE precedent_revocations (
    revocation_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    precedent_id UUID NOT NULL REFERENCES precedents(precedent_id) ON DELETE RESTRICT,
    revoked_by UUID NOT NULL,
    revoked_by_role VARCHAR(128) NOT NULL,
    revoked_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    reason TEXT NOT NULL,
    evidence_ref VARCHAR(512)
);

CREATE INDEX idx_revocations_lookup 
    ON precedent_revocations (precedent_id);

CREATE TABLE precedent_evidence (
    evidence_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    precedent_id UUID NOT NULL REFERENCES precedents(precedent_id) ON DELETE CASCADE,
    evidence_type VARCHAR(64) NOT NULL,
    source_uri VARCHAR(512) NOT NULL,
    content_hash VARCHAR(128) NOT NULL,          -- SHA-256 cryptographic digest of source doc
    retrieved_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE precedent_embeddings (
    embedding_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    precedent_id UUID NOT NULL REFERENCES precedents(precedent_id) ON DELETE CASCADE,
    embedding vector(1536) NOT NULL,             -- pgvector embedding for semantic discovery
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_precedent_embeddings_hnsw 
    ON precedent_embeddings USING hnsw (embedding vector_cosine_ops);

-- ============================================================================
-- 4. EPISODIC & OUTCOME STATE: Execution Ledger & Verifications (Layer 2)
-- ============================================================================

CREATE TABLE execution_events (
    event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    workflow_id VARCHAR(128) NOT NULL,
    agent_id VARCHAR(128) NOT NULL,
    entity_id UUID NOT NULL REFERENCES entities(entity_id) ON DELETE RESTRICT,
    applied_precedent_id UUID REFERENCES precedents(precedent_id),
    applied_policy_revision_id UUID REFERENCES policy_revisions(policy_revision_id),
    proposal JSONB NOT NULL,
    mutation_payload JSONB NOT NULL,
    rollback_payload JSONB,
    status VARCHAR(64) NOT NULL,                 -- "executed", "compensated", "rolled_back"
    executed_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_execution_events_entity 
    ON execution_events (entity_id, executed_at DESC);

CREATE TABLE decision_outcomes (
    outcome_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    event_id UUID NOT NULL REFERENCES execution_events(event_id) ON DELETE RESTRICT,
    observed_at TIMESTAMPTZ NOT NULL,
    outcome_status VARCHAR(64) NOT NULL,         -- "performing", "defaulted", "covenant_breached"
    metrics_snapshot JSONB NOT NULL,
    verification_type VARCHAR(64) NOT NULL,      -- "automated_pipeline", "human_audit", "external_feed"
    verified_by_id VARCHAR(128) NOT NULL,
    verification_timestamp TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_decision_outcomes_event 
    ON decision_outcomes (event_id, observed_at);

-- ============================================================================
-- 5. ADJUDICATION STATE: Dispute Lifecycle & Committee Escalations (Layer 5)
-- ============================================================================

CREATE TABLE adjudication_cases (
    case_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    event_id UUID REFERENCES execution_events(event_id),
    entity_id UUID NOT NULL REFERENCES entities(entity_id),
    initiator_id UUID NOT NULL,
    status VARCHAR(64) NOT NULL DEFAULT 'pending', -- "pending", "in_committee", "resolved", "dismissed"
    disputed_issue TEXT NOT NULL,
    resolution_type VARCHAR(64),                  -- "promoted_to_precedent", "policy_updated", "rejected"
    resolved_precedent_id UUID REFERENCES precedents(precedent_id),
    resolved_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_adjudication_status ON adjudication_cases (status);

How Do You Prevent State Decay? The Temporal Validity Engine

State is not permanently true merely because an authorized human once approved it.

In real-world enterprises, state decays along multiple vectors: * Fixed Time Windows: A temporary emergency pandemic exception expires. * Policy Version Supersession: The Risk Committee publishes Policy Rev 5.0, invalidating exceptions granted under Rev 4.2. * Authority Shifts: The executive who approved a local exception is replaced, or authority delegations narrow. * Dynamic Revalidation Triggers: A customer's risk tier changes, or source financial statements are withdrawn.

flowchart TD
    A["Agent Query Triggered"] --> B["Semantic Discovery via pgvector"]

    B --> C["Candidate Precedent Nodes Identified"]

    C --> D{"Deterministic Admissibility Filter"}

    D -- "Check 1: Temporal Window" --> E{"valid_from <= NOW() <= valid_until?"}
    E -- "Expired" --> F["Node INADMISSIBLE (Pruned)"]
    E -- "Valid" --> G{"Check 2: Active Policy Revision"}

    G -- "Policy Revision Active?" --> H{"Parent Policy Revision Active?"}
    H -- "Superseded" --> F
    H -- "Active" --> I{"Check 3: Append-Only Revocation"}

    I -- "Revocation Record Exists?" --> J{"precedent_revocations exists?"}
    J -- "Yes (Revoked)" --> F
    J -- "No" --> K{"Check 4: Applicability Predicate"}

    K -- "Scope & Context Match?" --> L{"Applies(N, E, C, t) = True?"}
    L -- "False" --> F
    L -- "True" --> M["Node ADMISSIBLE"]

    M --> N["Inject into Agent Context Window with Provenance Metadata"]

    style A fill:#18181b,stroke:#64748b,stroke-width:1.5px,color:#ffffff
    style B fill:#18181b,stroke:#3b82f6,stroke-width:1.5px,color:#ffffff
    style C fill:#18181b,stroke:#3b82f6,stroke-width:1.5px,color:#ffffff
    style D fill:#1e1b4b,stroke:#8b5cf6,stroke-width:2px,color:#ffffff
    style E fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style F fill:#450a0a,stroke:#ef4444,stroke-width:2px,color:#ffffff
    style G fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style H fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style I fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style J fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style K fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style L fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style M fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#ffffff
    style N fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#ffffff

The Expressive Applicability Formulation

A candidate precedent node $N$ is evaluated as admissible for target entity $E$ in current context $C$ at time $t$ under active policy revisions $\mathcal{P}_t$ using deterministic logic:

$$ \text{Admissible}(N, E, C, t, \mathcal{P}_t) \iff \begin{cases} \text{TemporalValid}(N, t) & \iff t_{\text{from}} \le t \le t_{\text{until}} \land t \le t_{\text{review}} \\ \text{Applies}(N, E, C, t) & \iff \text{Scope}(N) \sqsubseteq (E, C) \\ \text{PolicyActive}(N, \mathcal{P}_t) & \iff \text{ParentPolicyRevision}(N) \in \mathcal{P}_t \\ \text{AuthorityValid}(N, t) & \iff \text{RoleTier}(N.\text{authorizer}) \ge \text{ReqTier}(N) \\ \neg\text{Revoked}(N) & \iff \text{COUNT}(\text{precedent_revocations}) = 0 \\ \text{EvidenceSufficient}(N) & \iff \forall e \in N.\text{evidence}: \text{Available}(e) \end{cases} $$

This check runs in deterministic application code or SQL before context assembly. The system prevents inadmissible organizational state from ever governing an agent action.

How Does the Classification Gate Prevent Human Overrides From Corrupting State?

When a human supervisor overrides an agent's proposal, naive systems simply write the correction into a vector store or append it to a few-shot prompt. This pollutes the system with personal idiosyncrasies, political overrides, and unrepeatable exceptions.

The system should not learn from every correction. It should learn from corrections that have been classified, scoped, authorized, and validated.

The Classification Gate forces every human intervention through an explicit categorization schema:

flowchart TD
    A["Human Override Event"] --> B["Classification Gate"]

    B --> C1["1. Case-Specific Adjustment"]
    B --> C2["2. Reusable Precedent"]
    B --> C3["3. Policy Change"]
    B --> C4["4. Data Correction"]
    B --> C5["5. Contested Judgment"]

    C1 --> D1["Layer 2: Episodic Ledger<br/>(Local run only; zero propagation)"]
    C2 --> D2["Layer 3: Precedents<br/>(Scoped entity envelope + TTL)"]
    C3 --> D3["Layer 4: Policy Revisions<br/>(Governance review & unit tests)"]
    C4 --> D4["Layer 1: Structural State<br/>(Entity record mutation)"]
    C5 --> D5["Layer 5: Adjudication State<br/>(Quorum & committee review)"]

    style A fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style B fill:#1e1b4b,stroke:#8b5cf6,stroke-width:2px,color:#ffffff
    style C1 fill:#18181b,stroke:#64748b,stroke-width:1.5px,color:#ffffff
    style C2 fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#ffffff
    style C3 fill:#1e1b4b,stroke:#8b5cf6,stroke-width:1.5px,color:#ffffff
    style C4 fill:#18181b,stroke:#3b82f6,stroke-width:1.5px,color:#ffffff
    style C5 fill:#451a03,stroke:#f97316,stroke-width:1.5px,color:#ffffff
    style D1 fill:#09090b,stroke:#64748b,stroke-width:1px,color:#cbd5e1
    style D2 fill:#09090b,stroke:#10b981,stroke-width:1.5px,color:#cbd5e1
    style D3 fill:#09090b,stroke:#8b5cf6,stroke-width:1.5px,color:#cbd5e1
    style D4 fill:#09090b,stroke:#3b82f6,stroke-width:1px,color:#cbd5e1
    style D5 fill:#09090b,stroke:#f97316,stroke-width:1.5px,color:#cbd5e1

The Gate Authority Matrix: Who Governs the Gate?

How Do Precedents and Observed Outcomes Form a Compounding Flywheel?

The true defensibility of the ACG is that it turns static exception tracking into a compounding intelligence flywheel.

flowchart LR
    A["1. Policy Revision Active"] --> B["2. Agent Proposal"]
    B --> C["3. Supervisor Override & Classification"]
    C --> D["4. Governed Precedent in ACG"]
    D --> E["5. Autonomous Future Executions"]
    E --> F["6. Observed Real-World Outcomes"]
    F -. "Empirical Evidence Validates Precedent" .-> D
    F -. "Automated Promotion Recommendation" .-> A

    style A fill:#1e1b4b,stroke:#8b5cf6,stroke-width:1.5px,color:#ffffff
    style B fill:#18181b,stroke:#64748b,stroke-width:1.5px,color:#ffffff
    style C fill:#18181b,stroke:#f59e0b,stroke-width:1.5px,color:#ffffff
    style D fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#ffffff
    style E fill:#18181b,stroke:#3b82f6,stroke-width:1.5px,color:#ffffff
    style F fill:#09090b,stroke:#10b981,stroke-width:2px,color:#ffffff

Causality and Cohort Controls in Outcome Tracking:

Tracking outcomes is powerful, but engineering teams must guard against naive causal assumptions: * Cohort Comparability: Fifty successful loans under an exception may reflect a benign macroeconomic window or borrower selection bias rather than the safety of the exception rule itself. * Outcome Lag: In credit, healthcare, and engineering, catastrophic failures often take months or years to materialize. * Automated Promotion Recommendations (Not Automated Rewrites): Empirical outcome evidence can prioritize a precedent for formal committee review, but the system must never autonomously rewrite baseline policy without human governance sign-off.

What Governs State Transitions in Autonomous Delegations?

Before an autonomous agent executes a consequential state mutation, the ACG control plane enforces an explicit 7-Point State-Transition Contract:

This directly implements the Delegations-to-be-Supervised (DTBS) lifecycle across the five state domains:

The PM's State Domain Audit Matrix: 5 Verification Gates for Sprint & PRD Reviews

To ensure product managers can evaluate whether their autonomous agent architecture maintains state integrity across sprints, run this diagnostic checklist:

How Does an Underwriting Agent Execute Against Governed State in Production?

To see the five state domains, the Temporal Validity Engine, and the Classification Gate in action, trace an execution cycle:

sequenceDiagram
    autonumber
    participant Human as Senior Credit Officer
    participant Gate as Classification Gate
    participant Agent as Underwriting Agent
    participant DB as PostgreSQL State Store
    participant TVE as Temporal Validity Filter

    Agent->>DB: Query Precedents for Borrower X
    DB->>TVE: Run Admissibility Query (TTL, Scope, Policy Rev 4.2)
    TVE-->>DB: Filter Expired and Revoked Records, Retain Active Precedent
    DB-->>Agent: Ingest Admissible Precedent and Evidence Metadata

    Agent->>Agent: Generate Compliant Proposal with Proof Dossier
    Agent->>Human: Present Recommendation with Linked Evidence

    alt Human Confirms Recommendation
        Human->>Gate: Approve
        Gate->>DB: Log Execution Event and Rollback Payload
    else Human Refines Terms
        Human->>Gate: Adjust Covenant - Require Monthly Cash Flow Audit
        Gate->>Gate: Verify Senior Officer Authority Tier
        Gate->>DB: Update Precedent Scope and Log Execution Event
    else Human Disputes Exception Applicability
        Human->>Gate: Reject Exception Precedent
        Gate->>DB: Route to Adjudication State for Committee Hearing
    end

The Execution Trace:

1. The Ingestion Query: The Underwriting Agent queries PostgreSQL for applicable precedents matching Borrower X ($10M facility, DSCR 1.18x).
2. Admissibility Filtering: The database query filters candidate records through the Temporal Validity conditions (valid_until > NOW() AND parent_policy_revision_id = 'pol_rev_4_2' AND NOT EXISTS (SELECT 1 FROM precedent_revocations WHERE precedent_id = p.precedent_id)). Stale pandemic exceptions and revoked precedents are excluded at the SQL layer.
3. Inference Under Proof: The agent receives the valid precedent and generates an approval recommendation that explicitly references the active policy waiver, linked evidence hashes, and required covenants.
4. Supervised Human Review: The Senior Credit Officer reviews the structured proposal. Because the system presents the exact authorizer, policy dependency, and evidence chain together, supervisory verification friction is eliminated.
5. Compounding Mutation: The officer confirms the override with a minor covenant refinement. The Classification Gate validates the officer's role tier, updates the precedent's scope in precedents, and records the execution and rollback payload in execution_events.

Which Architectural Anti-Patterns Destroy State Integrity?

When engineering teams implement persistent state for AI agents, they frequently fall into five predictable traps:

The Adversarial Stress-Test: What Could Break an Accumulated Context Graph?

1. What is the strongest argument against this approach?

Relational and temporal governance of state introduces substantial engineering overhead compared to standard vector RAG pipelines. Designing, migrating, and maintaining schemas across five distinct state domains with strict foreign-key constraints, TTL invalidation sweeps, and classification gates demands significant systems engineering talent and slows down initial prototype velocity. For organizations where operational decisions carry low liability, the development velocity sacrifice of an ACG may outweigh its defensive benefits.

The Practical Resolution: Adopt a progressive implementation path. Start with PostgreSQL as a unified transactional store using standard relational foreign keys and pgvector. Do not build out all five state domains on day one; implement Structural State (Layer 1) and Policy State (Layer 4) first to enforce basic authority boundaries, and only graduate to Precedent State (Layer 3) once human override volume justifies structured exception indexing.

2. Under what circumstances would this fail?

The architecture fails if human operators routinely misclassify interventions at the Classification Gate. If senior reviewers develop "approval fatigue" and lazily designate ad-hoc, case-specific compromises as reusable enterprise precedents, the precedent layer accumulates poisoned or contradictory heuristics. Furthermore, if database query latency escalates due to unindexed recursive graph traversals or oversized JSONB payloads during live inference, agent execution will breach operational SLAs and cause fallback to unvetted defaults.

The Practical Resolution: Decouple precedent persistence from human review interfaces. When an operator records an override, route the entry to an asynchronous secondary review queue staffed by domain leads before promoting it to active Precedent State. To protect runtime SLAs, store compiled precedent evaluations in materialized denormalized caches with sub-millisecond retrieval keys, running complex recursive graph resolutions out-of-band.

3. What would a skeptical customer, client, or colleague object to?

A skeptical engineering leader will argue that building a complex custom state architecture inside PostgreSQL reinvents mature knowledge management platforms or distributed graph databases without their specialized tooling, risking distributed state divergence and endless schema migration friction.

The Practical Resolution: Emphasize that an ACG is not a generic knowledge base, but a transactional state machine governing autonomous agent authority. General-purpose knowledge tools lack transactional rollback guarantees, cryptographic audit hashes, and fine-grained temporal TTL enforcement. Keeping the ACG in PostgreSQL leverages existing enterprise disaster recovery, point-in-time recovery, and ACID transaction isolation natively without introducing distributed synchronization lag.

4. Which alternative deserves more consideration?

Externalized Policy Engines paired with hybrid lexical-vector retrieval. Instead of maintaining custom precedent tables and classification gates inside the operational database, an enterprise can standardize on Open Policy Agent (OPA) or Cedar for deterministic rule validation, leaving contextual memory in an enterprise search layer (like Elasticsearch or hybrid RAG). This separates governance entirely from application state and relies on battle-tested policy compilation rather than custom state-transition contracts.

The Practical Resolution: OPA and Cedar excel at evaluating deterministic boolean permissions, but they cannot represent historical episodic outcomes, evolving case-law precedents, or temporal exception decays natively. The optimal compromise uses OPA/Cedar as the runtime policy compiler for Policy State (Layer 4), while anchoring Precedent State (Layer 3) and Outcome State (Layer 2) within PostgreSQL to maintain continuous causal lineage between exceptions and observed business results.

5. What am I assuming that may not be true?

This architecture assumes that institutional knowledge and human exceptions can be cleanly factored into machine-evaluable conditional logic and relational schemas, whereas expert human judgment frequently relies on tacit domain intuition that defies structured parameterization.

The Practical Resolution: Design the Precedent State schema with explicit escape hatches. When a human override relies on tacit, non-quantifiable context, classify it as an isolated "Case-Specific Adjustment" (Type 1) rather than a reusable precedent. By restricting the ACG strictly to formalizable, empirical decision rules, the system maintains 100% deterministic integrity while reserving truly un-formalizable decisions for human review.

What Is the Core Architecture Invariant?

Enterprise AI defensibility depends on structuring institutional knowledge across governed state domains in PostgreSQL, transforming ephemeral model inferences into an auditable, compounding asset.

This post is part of the systems architecture series on Architecture of Proof. The strategic thesis was established in State Is the Moat in the AI World. This post established the concrete architectural blueprints for building the state layer. The next post examines runtime enforcement: Policy as Code: The Infrastructure Layer Between AI Governance Documents and Enforcement.