Open Reference Database Contract: Table Inventory and Control Boundaries

To turn AI governance into operational reality, we present our complete 60-Table Relational Schema Contract. This defines the relational evidence graph supporting the AI Governance and Evidence Infrastructure (AGEI) layers. Every table maps directly to tenant boundaries, policy states, receipts, agent actions, downstream provenance, shadow AI, and privacy controls.

A true data contract specifies more than a list of tables and columns—it defines structure, semantics, quality constraints, policy rules, and evolution. We provide downloadable artifacts for the actual contract (e.g., PostgreSQL DDL, constraints, RLS policies, indexes, JSON schemas, etc.) to make our open reference operational.

The Minimum Auditable Path

Before diving into all 60 tables, the schema is designed to answer the core governance questions through a minimum auditable path:

1. 1. Identity: Who or what acted?
2. 2. Authority: Who delegated permission, for what purpose and duration?
3. 3. Policy: Which versioned rule evaluated the requested action?
4. 4. Execution: Which exact tool and parameters were permitted?
5. 5. Evidence: What was attempted, what happened, and can it be verified?
6. 6. Privacy: What personal data was involved, retained, redacted, or held?

This is supported by a core evidence graph:

policy_version
  → gate_evaluation
  → pre_action_proof_bundle
  → agent_tool_invocation
  → request_receipt / outcome_receipt
  → receipt_batch / Merkle commitment
  → evidence_object / vault_object

This graph supports the central AGEI question: Was this action authorized, under which policy, by which delegation, using which tool and parameters, and what actually occurred? The separation of receipt_links from the receipt payload allows modeling of causation, sequence, supersession, parent-child events, and delegation lineage without overloading a single receipt row.

Critical Design Invariants

1. Treat organization_id as a Security Invariant

Calling organization_id an RLS anchor is not enough. The contract explicitly requires:

• organization_id NOT NULL on every tenant-owned row.
• Database-level RLS policies, not only API-layer filtering.
• A request-scoped tenant context set through a non-bypassable database role.
• Composite foreign keys that include organization_id where cross-tenant references could otherwise occur.
• Composite uniqueness, such as UNIQUE (organization_id, external_id).
• Explicit handling for global records, such as system policy templates or shared vocabulary terms.
• A prohibited-query test suite proving that a principal from Tenant A cannot read, join, insert, update, or reference Tenant B’s data.

2. Defining "Immutability"

Several rows are described as immutable (e.g., policy_versions, gate_evaluations, receipts). Immutability in this contract is enforced by:

• Revoking UPDATE and DELETE from application roles.
• An append-only database trigger.
• An application service that only permits event insertion.
• Database audit logging and privileged-access controls.
• Periodic Merkle batching with signed external commitments.
• External timestamping or WORM/object-lock retention.

For example, receipt_batches enforce inclusion proofs by recording batch_root_hash, previous_batch_root_hash, tree_algorithm, leaf_ordering_rule, signed_at, signer_key_id, external_commitment_reference, and external_committed_at.

3. Data Minimization and Receipt Hashes

Immutable event evidence does not require immutable personal content. A cryptographic hash can remain personal data when it can be linked back to a person. We establish the following privacy rules:

• Receipts contain opaque IDs and minimal event descriptors, not raw prompts, tool outputs, credentials, PII, or full customer records.
• Sensitive payloads live in evidence_objects or vault_objects, encrypted with tenant-scoped keys and access policies.
• Use separate evidence hashes for full confidential payloads and redacted/audit-safe renderings.
• Define a key-destruction or crypto-erasure model where lawful and technically appropriate.
• Never present a hash alone as proof that the underlying content is no longer personal data.
• Ensure audit_packs apply recipient-, purpose-, jurisdiction-, and data-classification filtering before export.

4. Strengthen the Proof-Bundle Contract

The pre_action_proof_bundles must bind the exact requested action, not only its general context. The execution system atomically marks the bundle consumed and issues an attempted-execution receipt before creating the external side effect, preventing replay attacks. The bundle contains:

proof_bundle_id, organization_id, agent_session_id, delegation_id, 
delegation_chain_hash, principal_id, tool_definition_id, tool_version, 
operation, canonical_parameter_hash, target_resource_hash, policy_version_id, 
policy_version_hash, gate_evaluation_id, risk_classification, approval_reference, 
issued_at, not_before, expires_at, single_use_nonce, consumed_at, 
consumption_receipt_id, signer_key_id, signature_algorithm, signature

Cross-Cutting Standards & Linkage Fields

To maintain high evidentiary value, we implement unified, cross-cutting linkage and cryptographic fields across our schemas:

• organization_id: Tenant boundary, acting as our Row-Level Security (RLS) anchor.
• policy_version_id: Binds any rule execution to the immutable policy state in force.
• gate_evaluation_id: Links domain action to a concrete gate outcome.
• receipt_id: Atomic evidence pointer for tamper-evident chain verification.
• evidence_object_id: Pointer to rich binary/structured payload data without bloating the domain table.
• content_hash / *_hash: Standardized SHA-256 hash over canonicalized payloads.
• hash_algorithm: Declares the hashing algorithm used (default SHA-256).
• canonicalization_version: Declares the serialization rule used before hashing (default ciaf-json-v1).
• signature / signature_algorithm / signed_by / signed_at: Ed25519 signatures provide cryptographic integrity and signer attribution for evidence artifacts, subject to documented key custody, rotation, revocation, timestamping, and verification procedures.

Complete Table Inventory by Family

1. Tenant, Identity, and API Access (13 Tables)

Establishes tenant isolation, principal authentication, API scopes, and usage logging.

• organizations (8 columns): Multi-tenant isolation with settings and settings hash.
• organization_members (13 columns): Maps users and roles inside organizations.
• principals (14 columns): Auth identities for users, services, and agent systems.
• api_clients (18 columns): Registers internal/external API clients.
• api_keys (23 columns): Stores hashed API keys (raw keys are never saved).
• api_key_service_grants (16 columns): Scopes keys to specific vault services.
• organization_service_entitlements (16 columns): Limits quotas, scopes, and gate bindings.
• ciaf_services (17 columns): Service catalog (e.g., events.submit, receipts.read).
• api_request_logs (30 columns): Connects API calls to receipts and gate evaluations.
• api_usage_daily (19 columns): Daily rollups for quota and abuse tracking.
• service_output_links (12 columns): Connects service outputs to evidence objects.
• webhook_endpoints (12 columns): Outbound webhooks.
• webhook_delivery_logs (18 columns): Log of outbound webhook payloads, with hashes.

2. Policy and Gate Enforcement (6 Tables)

Enforces versioned policies and collects rule-level evaluations.

• policy_sets (13 columns): Groups policy families (e.g., "Enterprise Validation").
• policy_versions (18 columns): Immutable policy payloads with payload hashes.
• policy_rules (15 columns): Individual rules extracted from the policy version.
• policy_evaluations (18 columns): Logs individual rule pass/fail outcomes.
• gate_definitions (20 columns): Defines enforcement triggers and failure actions.
• gate_evaluations (28 columns): Immutable gate outcomes (approve, deny, escalate, inspect).

3. Receipts, Evidence, Vault, Verification, and Audit Packs (11 Tables)

The custody substrate for tamper-evident packaging and independent verification.

• receipts (27 columns): Immutable event receipts with Merkle inclusion fields.
• receipt_links (10 columns): Chain-of-custody edges linking preceding receipts.
• receipt_batches (13 columns): Groups receipts under a Merkle root.
• receipt_batch_items (8 columns): Individual items with Merkle inclusion proof paths.
• evidence_objects (23 columns): Payloads or storage pointers matching external artifacts.
• vault_objects (19 columns): Cryptographically sealed custody records.
• verification_jobs (26 columns): Tracks signature, hash, and sequence verification runs.
• schema_versions (12 columns): Registry of JSON schema versions for payload verification.
• audit_packs (27 columns): Exportable compliance bundles with scope filtering.
• audit_pack_items (14 columns): Snapshots of receipts and objects in the export bundle.
• incidents (26 columns): Tracks anomalies or policy violations requiring investigation.

4. Lifecycle Object Registry and Lineage (2 Tables)

Tracks governed model-building inputs, outputs, and their lineage.

• ai_lifecycle_objects (23 columns): Registers datasets, training runs, model versions, and artifacts.
• ai_lifecycle_object_links (9 columns): Lifecycle lineage graph.

5. Agentic Governance and Pre-Action Proof (5 Tables)

Binds agent action to privilege elevation, delegation, and execution receipts.

• agent_sessions (16 columns): Session metadata, delegating principal, context hash.
• agent_delegations (14 columns): Scoped delegation chain with valid window and token hashes.
• agent_tool_definitions (15 columns): Catalog of tools, parameters, risk classes, and gates.
• pre_action_proof_bundles (18 columns): Gated proof token checked before execution.
• agent_tool_invocations (21 columns): Trace of execution, hashes, request, and outcome receipts.

6. Downstream Provenance and Watermarking (4 Tables)

Extends governance boundary to distributed documents and files.

• artifact_release_records (22 columns): Tracks release metadata, policy, and gates.
• watermark_descriptors (17 columns): Describes embedded steganographic or metadata markers.
• forensic_fingerprints (19 columns): fallback signature matching when direct watermarks are stripped.
• provenance_verification_records (18 columns): Logs downstream verification investigations.

7. Shadow AI Governance (4 Tables)

Discovers, classifies, and remediates unsanctioned tool use.

• shadow_ai_tool_registry (17 columns): Catalog of sanctioned, prohibited, or unmanaged tools.
• shadow_ai_discovery_records (22 columns): Logs signals of unmanaged tool access with data-sensitivity hints.
• shadow_ai_classifications (13 columns): Classifies risk based on data, task, and tool posture.
• shadow_ai_governance_responses (15 columns): Tracks remediation (education, migration, blocks).

8. Privacy, Data Rights, and Regulatory Evidence (14 Tables)

Integrates Article 30-style processing, lawful basis, DSRs, and legal holds. Note: This supports a Record of Processing Activities but does not automatically create GDPR compliance.

• processing_activities (35 columns): Maps activities directly to policies and receipts.
• data_subjects (20 columns): Pseudonymous subjects registry.
• data_subject_identifiers (17 columns): Hashed pointers to match requests without storing raw PII.
• lawful_basis_records (24 columns): Records GDPR-compliant lawful basis.
• consent_records (18 columns): Tracks consent status and lineage.
• cross_border_transfer_records (18 columns): Tracks transfer compliance and approvals.
• dpia_records (25 columns): Links DPIA assessments to policy states.
• data_subject_requests (28 columns): Tracks rights request workflows (DSRs).
• data_subject_request_actions (21 columns): Tracks redaction/erasure actions.
• personal_data_references (36 columns): Indexes location of personal data to support audits.
• privacy_redaction_events (28 columns): Records redaction events to ensure auditability.
• privacy_exports (23 columns): Tracks export packages linked to vault objects.
• retention_policies (16 columns): Retention rules mapped to policy versions.
• legal_holds (21 columns): Freezes scoped evidence when deletion is requested.

9. Extension Vocabulary (1 Table)

• ciaf_type_registry (9 columns): Controlled taxonomy for lifecycle, agent, and shadow AI types.

Missing Schema Components

To fully operationalize this contract, the following entities should be added or clearly placed in JSON payload contracts: