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. Four open-source reference surfaces enforce that field at runtime, vendor-neutral by design; expand one below for how it works, or read the note beneath for why all four matter together.
When a buyer signs off on a vendor's AI system, that approval now includes exactly which sensitive data fields the vendor is allowed to touch, how strongly each one has to be protected, and who's allowed to see the real value versus a masked version. Four separate open-source tools enforce that agreement automatically wherever the data actually flows, rather than relying on the vendor to remember and honor it.
Say a company approves a vendor to use certain customer data, but only some of it, and only in certain protected ways. Normally that agreement just lives in a contract that nobody checks against what the software is actually doing. Here, that same agreement is written into a real, structured record, and four different tools actually enforce it: they check, at the moment data is used, that nobody's touching more than what was agreed to.
One contract, four surfaces. 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). One procurement signature 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. Every read, reveal, and transform event lands on the same hash-chained audit-stream the rest of the Suite uses.
SURFACE 1 · TOKENIZE-BEFORE-INDEX
rag-sentinel
rag-sentinel
The retrieval-layer enforcer. Intercepts documents on the way into a vector store, tokenizes every data_vault_targets[] field per the Decision Card's protection level (None · Masked · Tokenized · Encrypted), and stamps the chunk with the vault-token reference. Embeddings index the token, never the raw value — so the index is procurement-clean even if the LLM is compromised.
- Where it sits: between your ingest pipeline and your vector DB
- Buyer outcome: a RAG corpus that can't leak fields procurement didn't authorize
SURFACE 2 · RBAC-AWARE REVEAL
deal-desk-workspace
deal-desk-workspace
The seat-of-work enforcer. A deal-desk operator UI that reads the Decision Card's reveal_roles for each vault field and renders accordingly — a sales engineer sees a token, a compliance officer sees the masked tail, a principal sees the unredacted value. Every reveal click writes a vault_field_revealed event into the audit-stream with the role, the field, and the token reference.
- Where it sits: the human-in-the-loop surface for vault data
- Buyer outcome: a reveal log that survives an audit without a SIEM lift
SURFACE 3 · TRANSFORM PIPELINE LIB
kg-skyyflow-klaviyo-bridge
kg-skyyflow-klaviyo-bridge
The marketing-connector enforcer. A TypeScript bridge library that sits between a vault and an outbound marketing platform (Klaviyo) — the buyer's Decision Card describes which fields can flow through to which downstream lists, in which protection state (raw / masked / tokenized). Every transform is a typed pipeline step with a reversible test fixture; nothing leaves the bridge that wasn't authorized in writing.
- Where it sits: the egress edge of your marketing stack
- Buyer outcome: a connector that ships a contract change in PR, not a hot deploy
SURFACE 4 · VISUAL OPERATOR CONSOLE
skyyflow-klaviyo-bridge-console
skyyflow-klaviyo-bridge-console
The operator-readable companion to the bridge library. React 19 + slate-indigo Bento dashboard: live sync log of each transform run, dead-letter queue with retry semantics, a Schema Mapper page that diffs the active Decision Card's data_vault_targets[] against the connector configuration, and a Security Assets page that lists what's tokenized vs. what's still raw. The operator console for a contract, not just a connector.
- Where it sits: alongside the bridge for ops + procurement review
- Buyer outcome: a single screen procurement can audit between renewals
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.
Suite × Implementations — the repos that implement it
The Suite is a set of specs — this is the open-source software that implements them: CI-green, semver-tagged, MIT-licensed repos, grouped below by the buyer persona who reaches for each one first. Five cross-ecosystem hooks and three runtime-enforcement layers chain the busiest of them together — unpacked inside the Procurement reviewer and Runtime enforcement groups below.
Procurement reviewer 2 repos
Five cross-ecosystem hooks chain these into one system: procurement-decision-api (below) drafts Decision Cards → policy-as-code-engine turns conditions into runtime gates → data-contract-registry extracts owners → csv-data-quality-rs validates CSVs row-by-row → sql-contract-enforcer compiles cross-dialect DDL.
FastAPI service that drafts AI Procurement Decision Cards from a buyer rubric and a set of vendor Suite documents (AEO + agent-card + tool-card + ai-evidence + …). The first cross-ecosystem bridge in the portfolio — Suite × Decision Intelligence.
NIST RMF: GOVERN 5.1, MAP 3.1, MEASURE 2.5, MANAGE 1.2 (Full)
View on GitHub →Declarative policy evaluator. Headline: POST /bundles/from-decision-card turns a Decision Card's conditions[] into a runtime-enforceable PolicyBundle. Closes the loop from "buyer signed off" to "request gated." Cross-ecosystem hook #2.
Composes with: procurement-decision-api (in this group — hook #2 consumes its Decision Cards)
AEO consumer / spec implementer 4 repos
The 5-layer AEO Reference Stack, in order: SDKs → CLI → Crawler → aeo-validator-service (Layer 4) → aeo-graph-explorer-rs (Layer 5, below).
Always-on HTTP validator for AEO + all 11 Suite docs. Auto-detects the spec via *_version sniffing, hashes canonically, tracks drift across re-checks (POST /watches/{id}/recheck returns a structured DriftReport). Layer 4 of the AEO Reference Stack.
Composes with: aeo-graph-explorer-rs (in this group — receives a JSONL feed from this service)
HTTP graph-query service over aeo-crawler JSON-Lines output. axum + petgraph, atomic POST /ingest, exposes /nodes · /neighbors · /shortest-path · /find-by-claim. The fifth layer of the AEO Reference Stack — 3→5 layers gap closed.
Composes with: aeo-validator-service (in this group — drift detection across watches)
Walks the Suite graph from an IncidentCard and emits a structured remediation plan: DecisionCard → RecheckPolicy, Vendor → RequestReview, AEO/agent/tool → Revalidate.
Composes with: drives policy-as-code-engine (per the composition diagram: "ICR -.->|drives| PAC")
Sign + verify Suite documents with ed25519 over the same canonical-hash convention every other Suite repo uses. The missing "this AEO actually came from the vendor" layer. Vendors sign, publish a well-known public key URL, consumers verify before they trust the document.
Composes with: aeo-validator-service (in this group — tamper events) and procurement-decision-api (Procurement reviewer group above — signed Decision Cards)
NIST RMF: MAP 2.2 (provenance), MEASURE 2.8 (transparency)
View on GitHub →
Data team 3 repos
One contract, two enforcement paths: data-contract-registry defines it, csv-data-quality-rs validates CSV rows against it, sql-contract-enforcer compiles it to database DDL.
Schema registry with semver versioning, compatibility checks (backward / forward / full), declared owners, freshness SLAs. POST /contracts/owners/from-decision-card pulls Owner records out of a Procurement Decision Card. Cross-ecosystem hook #3.
Composes with: procurement-decision-api (Procurement reviewer group above — hook #3); feeds csv-data-quality-rs (hook #4) and sql-contract-enforcer (hook #5)
Streaming CSV validator against a data-contract-registry contract. Async, row-by-row, structured violation report (required / bad_type / enum_mismatch / column_count_mismatch / invalid_json). Cross-ecosystem hook #4.
Composes with: data-contract-registry (hook #4)
Turns a data-contract-registry contract into enforceable cross-dialect DDL (CHECK / NOT NULL / UNIQUE / PK / FK) for Postgres, MySQL, Snowflake, BigQuery, plus a contract-vs-schema checker for CI. Dialect-aware (BigQuery demotes CHECK/UNIQUE to comments + PK/FK to NOT ENFORCED). Cross-ecosystem hook #5.
Composes with: data-contract-registry (hook #5); enforces at the database-table runtime layer alongside the Runtime enforcement group below
SRE / Platform reliability 5 repos + 4 grouped predecessors
The README claims "Ten repos" here; the table only names 9 — 5 described below (including audit-stream-py, the spine this stack writes to) plus 4 more grouped under "Plus 5 earlier reliability repos" (itself claims 5, names 4). Two count mismatches, carried here rather than rounded off.
SLO + error-budget library, multi-window burn-rate alerts (SRE workbook threshold 14.4).
Composes with: mcp-reliability-toolkit (shares its SLO-burn math); audit-stream-py (in this group — the spine every repo in this stack writes to)
Token-bucket rate limiter · 3-state circuit breaker · exponential-backoff retry with jitter · bulkhead.
Composes with: mcp-reliability-toolkit (emits configs based on this repo's primitives)
Server-side flag eval — targeting rules, sticky percentage rollouts (SHA-256 bucketing, no RNG), hot reload.
View on GitHub →Async request mirroring with sampling + divergence detection. The SRE primitive for safe migrations.
View on GitHub →Append-only governance event stream for the whole portfolio. Hash-chained for tamper-evidence; Server-Sent Events for live tailing; REST for queries. Every other portfolio repo is a producer — decision_card_drafted, policy_bundle_registered, watch_drifted, attestation_verified, contract_promoted, incident_filed.
20+ event kinds across 10 producer repos · GET /verify walks the chain end-to-end
"Defense-in-depth predecessors" — the README's own collective description, applied to all four names in this row; no individual write-up exists for any of them. Verbatim README row: "(Plus 5 earlier reliability repos) | Python | rate-limit-shield · identity-mesh · agent-canary · model-registry-pro — defense-in-depth predecessors." That row claims 5 earlier repos but names only 4 — an internal mismatch in the source, not one introduced here. All four are confirmed to exist (GitHub API returns HTTP 200 for each), but none of the four names is hyperlinked anywhere in the README — they appear only as a bare code span — so the links below follow the org's github.com/mizcausevic-dev/<repo-name> pattern used by every other repo in this document: pattern-inferred, not source-confirmed.
MCP / Claude integrator 3 repos
Three MCP servers for three integration surfaces — the README calls the latter two "sibling MCP servers … for narrower use cases" alongside the unified mcp-kinetic-gain.
Unified Suite MCP server — 75 tools across 12 specs + DefenseTech 8-pack (v0.9.1, on the official MCP Registry). One Claude Desktop config entry. Headline tools: aup_check_compliance (joins AUP + Disclosure into one allow/deny call); decision_card_validate (enforces the full Decision Card conditional rule set); defensetech_vault_resolve_3axis (resolves CUI × export-control × foreign-person to the most-restrictive vault policy).
Composes with: mcp-reliability-toolkit, mcp-decision-intelligence (README calls these "sibling MCP servers … for narrower use cases")
Reliability MCP server — compute_slo_burn, design_rate_limiter, design_circuit_breaker, compose_reliability_pattern. Same math as slo-budget-tracker; emits Python + Rust configs.
Composes with: slo-budget-tracker, reliability-toolkit-rs
Decision Intelligence MCP server — validate_decision_card, preview_policy_bundle, plan_incident_remediation, check_contract_compatibility. Read-only preview of what the live Python/Rust services would compute.
Composes with: procurement-decision-api (featured above), policy-as-code-engine, incident-correlation-rs, data-contract-registry — the live services it previews
Runtime enforcement 2 repos
The Decision Card enforces at three runtime layers: the MCP tool call (mcp-permission-broker), the Azure OpenAI call (azure-openai-governance-bridge), and the database table (sql-contract-enforcer, Data team group above).
Runtime gate between a Decision Card and an MCP tool call. Composes Decision Card conditions into deny-trumps-allow PolicyBundles; emits tool_invocation_* to the spine.
Composes with: azure-openai-governance-bridge (its "Azure-native sibling"); audit-stream-py (SRE / Platform reliability group above — the spine); enforces Decision Cards produced by procurement-decision-api
The Azure-native sibling — an Azure Function in front of Azure OpenAI enforcing the same PolicyBundle contract on every chat-completion call (deployment + each declared tool). Puts the Suite's governance on the data path enterprises actually run AI on.
Composes with: mcp-permission-broker (sibling)
Every individually-described repo above is grouped exactly as the meta-repo's Suite × Implementations section groups it — the README documents the same stack in prose form, though it still headlines a "fifteen-repo" count under correction.