Spec #11 · Cross-cutting · v0.1 draft

What did your buyer actually decide?

The first ten Kinetic Gain Protocol Suite specs cover vendor declarations — what an AI system claims about itself. The AI Procurement Decision Card closes the loop with the buyer-side artifact: a school district, a hospital, or a federal agency publishes its review outcome at a well-known URL, citing the vendor documents reviewed (by URL + content hash), the rubric used, conditions attached, and the appeals pathway. The decision finally enters the same machine-readable graph as the vendor's declaration.

Read the spec Try the visualizer

Cites vendor docs by URL + content_hash — drift is detectable, decisions are auditable
Seven terminal statuses — approved · approved-with-conditions · rejected · rejected-with-remediation · pending · withdrawn · expired
Served at /.well-known/decisions/<decision_id>.json

Why a Decision Card?

Today, a district that vets an EdTech AI tool, a hospital that evaluates a clinical AI tool, and a federal agency that adds a vendor to an Approved Vendor List record their decisions in procurement-office filing cabinets. The vendor publishes a machine-readable disclosure; the buyer's response is unstructured prose, scattered across PDFs and inboxes. The Decision Card fixes that. Outcomes become first-class documents in the Suite graph — searchable, verifiable, cross-referenced against the vendor declarations they cite.

The buyer is named

The buyer block declares the organization that conducted the review — a school district, a hospital, a federal agency. Decisions are attributable, not anonymous.

Subject is hash-bound

The subject.documents_reviewed[] array cites every vendor document by URL plus content_hash. If the vendor's AEO or Clinical AI Card changes after the decision, drift is detectable.

Conditions are machine-readable

Approval-with-conditions and rejection-with-remediation use the same conditions[] array. Each carries an ID, type, owner, deadline, and verification URI. They feed straight into runtime policy gates.

Appeals are first-class

Rejected vendors get a structured appeals block with deadline + process URL. Buyers MUST honor the deadline; vendors MUST be able to point to it.

History is append-only

State transitions accumulate in history[] — pending → approved-with-conditions → withdrawn. Auditors replay the chain instead of asking what happened.

Signatures optional, expected

For non-repudiation, decisions carry ed25519 signatures over the canonical-JSON hash — same convention as hash-attestation-rs. "This decision actually came from this buyer."

Document structure

Six fields are required: decision_card_version, decision_id, issued_at, buyer, decision, subject, and rationale. Everything else is optional but recommended.

{
  "decision_card_version": "0.1",
  "decision_id": "SPRINGFIELD-DEC-2026-001",
  "issued_at": "2026-05-14T19:00:00Z",

  "buyer":          { ... who is the buyer ... },
  "decision_maker": { ... role of the deciding party, optional ... },
  "decision":       { "status": "approved-with-conditions", ... },
  "subject":        { ... what vendor + documents were reviewed ... },
  "criteria":       { ... policies and rubric used ... },
  "conditions":     [ ... attached conditions, if any ... ],
  "rationale":      "Free-form prose explaining the decision.",
  "history":        [ ... audit trail of state transitions ... ],
  "appeals":        { ... appeal deadline + process URL ... },
  "publication":    { ... publication URL + visibility ... },
  "signatures":     [ ... non-repudiation signatures ... ],
  "withdrawal":     { ... only present if status=withdrawn ... }
}

Decision statuses

Status	Meaning
`approved`	Use is approved, no conditions attached.
`approved-with-conditions`	Use is approved subject to the listed `conditions`.
`rejected`	Use is declined. No remediation pathway offered.
`rejected-with-remediation`	Use is declined; `conditions` describe what would change the answer.
`pending`	Review is in progress; no terminal decision yet.
`withdrawn`	A previous decision is revoked; `withdrawal` block explains.
`expired`	The decision's `effective_until` date has passed.

Canonical example fixtures

Three example Decision Cards ship with the spec, one per regulated vertical. All three validate against decision-card.schema.json on every CI run.

EdTech · K-12 district

`district-edtech-approved-conditions.json`

Approved-with-conditions on an AI tutor — three contractual, audit, and technical conditions. Cites the vendor's Tutor Card, AEO, and Agent Card by hash; references the district's published Classroom AI AUP as criteria.policy_uris.

HealthTech · Hospital

`hospital-clinical-rejected.json`

Rejected-with-remediation. The vendor's FDA 510(k) clearance scope doesn't match the proposed deployment, and the bias audit's measurement cohort lacks the hospital's predominant patient population. conditions describe what would change the answer.

Federal · Civilian agency

`federal-agency-approved.json`

Approved for non-rights-impacting use per OMB M-24-10 + the NIST AI Risk Management Framework rubric. Demonstrates the criteria.policy_uris pattern for executive-order-driven procurement.

Composes with the rest of the Suite

A Decision Card references vendor documents via subject.documents_reviewed[].url. Suite tooling treats it as a first-class node in the same graph as every vendor declaration:

Resolve the referenced vendor documents at their well-known URLs and re-validate them at decision time.
Verify the content_hash to detect document drift after the decision was issued.
Aggregate multiple Decision Cards about the same vendor (e.g. "what percentage of K-12 districts approved AcmeTutor under their AUPs?").
Cross-check a Decision Card's criteria.rubric against the buyer's own published Classroom AI AUP via criteria.policy_uris.

The Decision Intelligence stack

Two production-shaped reference implementations consume Decision Cards directly. A third — the unified MCP server — exposes them to Claude through a single config entry.

procurement-decision-api ↗

Python · FastAPI · Pydantic v2. The first cross-ecosystem bridge in the portfolio. Drafts Decision Cards from a buyer rubric + the vendor's Suite documents (AEO + agent-card + tool-card + ai-evidence + clinical / tutor / AUP as applicable). NIST AI RMF crosswalk linked from the OpenAPI spec.

policy-as-code-engine ↗

Python · FastAPI. Companion to procurement-decision-api. 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."

incident-correlation-rs ↗

Rust · petgraph. Walks the Suite graph from an AI Incident Card and emits a structured remediation plan. DecisionCard → RecheckPolicy: when an incident references a previously-approved vendor, the engine flags the relevant decisions for re-review.

mcp-decision-intelligence ↗

Python · MCP server. Four tools — validate_decision_card, preview_policy_bundle, plan_incident_remediation, check_contract_compatibility. Read-only deterministic preview of what the rest of the stack would do, no LLM-in-the-loop reasoning.

validator.kineticgain.com ↗

Hosted validator. Paste any Decision Card JSON, get inline validation against the schema. Auto-detects the spec via the decision_card_version field — same pattern as the other ten Suite specs.

mcp-kinetic-gain ↗

Unified MCP server. Exposes the Decision Card alongside all 10 other Suite specs as MCP tools. Headline relevant tool: decision_card_validate enforces the full conditional ruleset (e.g. "if status is approved-with-conditions, conditions[] MUST be non-empty").

The eleventh spec closes the loop.

Vendors declare. Buyers decide. The graph is complete.

Read the spec on GitHub See the full Suite

Executive tools on kineticgain.com

The apex domain hosts four browser-only tool surfaces buyers and operators reach for alongside the Suite specs: /calculators/ — six math-rubric decision calculators (AI build-vs-buy, cloud replatform ROI, compliance cost of delay, security breach exposure, AI use-case prioritizer, vendor renewal decision). /trust/ — the eight-tool Trust Pack (AI System Card Builder, Evidence Locker, Shadow AI Discovery, AI Vendor Intake, AI Incident Tabletop Kit, Executive Risk Register, Subprocessor Disclosure Template, Vendor AI Disclosure Review). /kill-list/ — the eight-category complexity tax audit. /policies/ — the 10-vertical readiness spec aggregator that points back at the specs documented here. Static pages, browser-only, no login, no telemetry.