The open-source stack,
mapped by buyer persona.
The 23 real open-source repos that implement the Kinetic Gain Protocol Suite specs, grouped by buyer persona, plus the Vault Contract Pattern.
The Vault Contract Pattern — one Decision Card field, four reference surfaces
The AI Procurement Decision Card includes data_vault_targets[] to declare candidate field protections and reveal roles. The four open-source surfaces below illustrate where an approved contract could be applied. Their presence in source does not establish a buyer-signed card, a shared production route, or complete audit delivery.
A Decision Card can record which sensitive fields a buyer approves, how they should be protected, and which roles may see them. These four projects explore how to carry those rules into different workflows. Each deployment still needs a real buyer approval, trusted identity and policy facts, an integrated data path, and tests of the actual boundary.
A company could write down which customer fields a vendor may use and how to protect them. These projects show possible places to check that record, such as document ingest and a human review screen. They are reference software; a working, buyer-approved deployment must still be connected and tested.
One proposed contract, four integration points. The schema uses vault-oriented field names, while adapters may target different vaults. No single signed buyer contract has been verified flowing through all four projects, and their event paths have not been proven complete against an independently held audit checkpoint.
SURFACE 1 · TOKENIZE-BEFORE-INDEX
rag-sentinel
rag-sentinel
Reference retrieval-layer checks for data_vault_targets[] before vector indexing. A real ingest pipeline must be wired to the checks and tested for bypass paths before claiming raw fields cannot enter the index.
- Where it sits: between your ingest pipeline and your vector DB
- Review goal: prove protected fields do not enter the index through any ingest path
SURFACE 2 · RBAC-AWARE REVEAL
deal-desk-workspace
deal-desk-workspace
Reference operator UI for role-aware reveal decisions using reveal_roles. A production claim requires trusted caller identity, server-side authorization, and an accepted durable event for each reveal; a display state alone is insufficient.
- Where it sits: the human-in-the-loop surface for vault data
- Review goal: verify authorized reveals and independently check the audit record
SURFACE 3 · TRANSFORM PIPELINE LIB
kg-skyyflow-klaviyo-bridge
kg-skyyflow-klaviyo-bridge
TypeScript bridge library for evaluating field transforms before outbound marketing sync. The intended Decision Card mapping still needs a real buyer decision, live provider testing, and egress-path proof before claiming unauthorized fields cannot leave.
- Where it sits: the egress edge of your marketing stack
- Review goal: make mapping changes reviewable and test outbound field behavior
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
- Review goal: show operators the configured mapping and observed sync evidence
How it could compose. The four repositories use related Decision Card fields, but no shared buyer-approved runtime has been verified. Deploy each adapter behind a trusted identity and policy boundary, then test its ingest, reveal, egress, and audit behavior independently. The schema creates a common contract shape; source-level compatibility is not a complete enforcement or audit claim.
Suite × Implementations — the repos that implement it
The Suite is a set of specs; these are related source repositories grouped by likely user. Their cross-repo hooks are integration patterns. A source repo or passing local test does not establish a deployed, authenticated, buyer-approved request path.
The same 6 persona groups below, mapped by real repo count. Click a hub to filter, click a leaf for the real repo name and language. Tab through with a keyboard; Enter/Space activates a node like a click.
Procurement reviewer 2 repos
The proposed integration path links Decision Card drafting, candidate policy generation, owner extraction, CSV validation, and DDL proposals. Each handoff needs its own target-system test and trusted facts.
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 reference evaluator. POST /bundles/from-decision-card can generate a candidate PolicyBundle from a reviewed, signed card. Runtime denial still needs an integrated request path, trusted identity and condition facts, and a revocation source.
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).
Reference HTTP validator for AEO and Suite documents. It auto-detects a spec via *_version, hashes canonically, and can report drift across re-checks. Current hosted availability and twelve-spec coverage require a fresh independent check.
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")
Reference ed25519 signing and verification over canonical document hashes. A valid signature proves possession of the supplied key; the consumer must establish the key owner's identity through a trusted channel.
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 model can feed CSV validation and database DDL proposals. Generated SQL must be executed and rolled back in the intended database before calling it an enforcement path.
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)
Generates dialect-specific DDL proposals from a contract model and can compare a contract with an observed schema. Constraints differ across Postgres, MySQL, Snowflake, and BigQuery; generated DDL has not been executed or rolled back on a target database.
Composes with: data-contract-registry as a candidate adapter; database execution remains a release gate
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).
Related: mcp-reliability-toolkit shares SLO-burn math; optional audit integration needs producer-by-producer proof
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 →Optional event sink with a hash chain over accepted events, Server-Sent Events, and REST queries. Each producer needs an authenticated integration and checked receipt. Chain continuity cannot detect events that were never delivered.
GET /verify checks the accepted chain; completeness needs durable receipts and an independently held checkpoint
"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 local stdio MCP server — 75 tools across 12 specs, including the DefenseTech 8-tool pack (v0.10.0 on npm and the official MCP Registry). aup_check_compliance compares declared AUP and disclosure fields; its allow result is not an authorization grant. decision_card_validate checks the card's schema and conditions; defensetech_vault_resolve_3axis computes a policy preview from supplied facts. The published server does not gate downstream handlers.
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.
Related reference repos: procurement-decision-api, policy-as-code-engine, incident-correlation-rs, and data-contract-registry; this MCP server provides a read-only preview, not a live service call
Runtime gate candidates 2 repos
These source projects target MCP and Azure OpenAI call paths; sql-contract-enforcer proposes database DDL. The signed-card one-tool MCP integration is draft and unmerged. No buyer identity, trusted condition source, private hosted route, complete independent audit checkpoint, or target database execution has been verified for production.
Reference Broker for evaluating signed-card conditions with deny-trumps-allow semantics. A source-only one-tool integration is under review. It is not part of the published stdio package and has not been exercised at a private hosted boundary with real buyer facts or durable revocation.
Related: azure-openai-governance-bridge and audit-stream-py; integration and accepted audit receipts need deployment evidence
Reference Azure Function for evaluating a PolicyBundle before an Azure OpenAI request. A live private route, issuer and caller facts, revocation, denial behavior, and rollback have not been verified here. It should not be read as evidence that every production completion call is gated.
Composes with: mcp-permission-broker (sibling)
The selected repositories above are linked individually. The Suite meta-repo has deeper architecture notes; the public account index covers the wider estate. Grouping here does not assert a deployed integration.