Open governance protocols
for the agent era.

The suite at a glance

Each spec carries a top-level <name>_version field. The unified visualizer auto-detects which spec a document is in by inspecting that field. The MCP server exposes fetch / validate / inspect / cross-spec-join tools for all eleven specs.

Two front doors

The hosted validator is the buyer-side entry point — paste a vendor's JSON, get a procurement-grade report. The unified MCP server is the agent-side entry point — every spec becomes a callable tool. Eleven specs, two front doors.

open https://validator.kineticgain.com

npx -y mcp-kinetic-gain validate <files...>

The Vault Contract Pattern — one Decision Card field, four runtime surfaces

The AI Procurement Decision Card v0.2 added a single field — data_vault_targets[] — that names the fields a buyer authorizes a vendor to read, the protection level required at rest, and the roles permitted to reveal them. That one field is the spine of a complete vault contract: the buyer signs it as part of procurement, four open-source reference surfaces enforce it at runtime, and every read/reveal/transform event lands on the same hash-chained audit-stream the rest of the Suite uses.

The pattern is vault-vendor-shaped but vendor-neutral — the field names match Skyflow's vault-contract vocabulary, but the runtime targets work against any tokenization vault (Skyflow, Privacera, Very Good Security, in-house). What buyers get is a single procurement signature that travels into the retrieval index, the deal-desk UI, the marketing connector, and the operator console — without any of them learning a raw PII value they aren't authorized to see.

How it composes. The four surfaces don't share a runtime — they share the same JSON field on the same procurement document. A vendor accepts the Decision Card; rag-sentinel reads data_vault_targets[] to decide what tokenizes on ingest; deal-desk-workspace reads reveal_roles to decide who sees what at the UI; kg-skyyflow-klaviyo-bridge reads the protection levels to decide what propagates to Klaviyo; and the bridge console reads all of the above to render the live posture. One signature, four enforcement layers, one audit trail — and any of the four is opt-in. Buyers can adopt the pattern incrementally without committing to a fifth vendor.

The audit-stream spine — one log, eleven producers, five runtimes

Every governance moment in the portfolio writes to the same hash-chained log. Decision Cards drafted, AEO watches drifted, policy bundles deployed, requests denied at runtime, MCP + Azure OpenAI tool invocations gated, Postgres rows changed, WordPress content published, data contracts broken in CI, signatures verified or tampered, AEO graphs ingested, incidents correlated to remediation plans — one tamper-evident narrative an auditor can replay end-to-end. Producers fail safely: if audit-stream-py is down, governance still happens, the event is just logged to stderr instead of the chain. Same opt-in env-var contract (AUDIT_STREAM_URL) across all eleven, spanning Python, Rust, PL/pgSQL, PHP, and Azure Functions.

flowchart LR
    PDA["procurement-decision-api
Python · FastAPI"] -->|"decision_card_drafted"| AS
    AVS["aeo-validator-service
Python · FastAPI"] -->|"watch_created
watch_drifted
watch_validity_flipped"| AS
    PCE["policy-as-code-engine
Python · FastAPI"] -->|"policy_bundle_registered
request_allowed
request_denied"| AS
    DCR["data-contract-registry
Python · FastAPI"] -->|"contract_promoted
contract_deprecated
contract_compatibility_failed"| AS
    HA["hash-attestation
Rust · crypto library"] -->|"attestation_signed
attestation_verified
attestation_failed"| AS
    ICR["incident-correlation
Rust · graph library"] -->|"incident_correlated
incident_correlation_failed"| AS
    AGE["aeo-graph-explorer
Rust · axum service"] -->|"graph_ingested
graph_ingest_failed"| AS
    MPB["mcp-permission-broker +
azure-openai-governance-bridge
Python · runtime gates"] -->|"tool_invocation_allowed
tool_invocation_denied
tool_invocation_required_approval"| AS
    PGX["pg-audit-stream-extension
PL/pgSQL · pg_notify"] -->|"table CRUD events"| AS
    WPA["wp-kinetic-gain-audit
PHP · WordPress/MySQL"] -->|"content_published
plugin_activated
user_role_changed"| AS

    AS{{"audit-stream-py
hash-chained · tamper-evident
SSE live tail · REST query · GET /verify"}}

    AS --> CON1["governance dashboards"]
    AS --> CON2["compliance evidence"]
    AS --> CON3["SRE alerting"]

    classDef producer fill:#0b3b3a,stroke:#10b981,color:#e6fffa,stroke-width:1.5px;
    classDef spine fill:#10b981,stroke:#34d399,color:#022c22,stroke-width:2px;
    classDef consumer fill:#1e293b,stroke:#475569,color:#cbd5e1,stroke-width:1px;
    class PDA,AVS,PCE,DCR,HA,ICR,AGE,MPB,PGX,WPA producer;
    class AS spine;
    class CON1,CON2,CON3 consumer;
          

20+ event kinds across 11 producers, all funneling into one verifiable chain. The Rust libraries ship behind a Cargo feature (--features audit-stream) so consumers who don't need emission can strip out the HTTP dep. The data-tier producers prove the reach: pg-audit-stream-extension catches direct DML the app path would miss, and wp-kinetic-gain-audit brings the same tamper-evident chain to any WordPress estate. Adding the next producer is a ~60-line module: copy the pattern, pick your event kinds, point at AUDIT_STREAM_URL.

NIST AI RMF crosswalk

Federal and enterprise procurement teams operating under OMB Memorandum M-24-10 can use this crosswalk to map every Suite spec — and the 15-repo implementation stack — to specific NIST AI RMF subcategories. The AI Procurement Decision Card (spec #11) is the natural carrier for RMF-aligned procurement outcomes — its criteria.rubric field can record per-subcategory pass / partial / fail results for any vendor review. Crosswalk v0.2 (2026-05-15) adds Section 7 mapping the implementation tooling to NIST subcategories it actively operationalizes — policy-as-code-engine converts MANAGE 1.3 from policy text to runtime gate; audit-stream-py closes the GOVERN 1.5 record-keeping leg; aeo-validator-service + slo-budget-tracker close MEASURE 3.1 continuous-monitoring.