Buyer-side spec · Cross-cutting · v0.1 draft

What did your buyer actually decide?

Kinetic Gain Protocol Suite documents 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 decision 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 names the organization the card claims conducted the review — a school district, hospital, or federal agency. Verify that claim against a trusted source before attributing the decision to that buyer.

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. These fields are structured for integration with runtime policy gates; enforcement requires a separately deployed, trusted path.

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 records transitions

The history[] array records state transitions — pending → approved-with-conditions → withdrawn. A durable, tamper-evident audit trail requires separate storage and verification controls.

Signatures optional, expected

A verified Ed25519 signature over the canonical-JSON hash links a card to its signing key. It identifies the buyer only when the verifier also trusts an independent binding between that key and the named buyer. The signing convention follows hash-attestation-rs.

Document structure

Seven 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":     [ ... optional Ed25519 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. POST /bundles/from-decision-card translates a Decision Card's conditions[] into a PolicyBundle for evaluation. Gating real requests requires a separately deployed, trusted policy path.

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 ↗

TypeScript · MCP server. Four tools — validate_decision_card, preview_policy_bundle, plan_incident_remediation, check_contract_compatibility. Read-only deterministic preview of the corresponding service behavior.

validator.kineticgain.com ↗

Hosted validator. Paste a Decision Card JSON document for inline schema validation. It detects the document via the decision_card_version field.

mcp-kinetic-gain ↗

Unified MCP server v0.10.0. Offers 75 tools for all twelve Suite specs, DefenseTech checks, and implementation previews. decision_card_validate checks conditional document rules, including the non-empty conditions[] requirement for approved-with-conditions cards; it does not authorize a live tool call.

Put the buyer's review on record.

Vendor declarations and the review outcome can be checked together.

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.