Development Receipt v1
Process provenance for AI-assisted development. A signed JSON artefact proving what governance regime was active when AI wrote your code.
Why process provenance matters
Your AI Bill of Materials (AIBOM) tells auditors what models you used. It doesn't tell them whether those models operated under governance constraints. The Development Receipt fills that gap.
Verifiable
SHA-256 self-attestation over all receipt fields. Tamper-evident without HSM infrastructure. Any third party can recompute and verify.
Governance-bound
Records which DevContract clauses were evaluated, which passed, which failed, and the overall verdict: compliant, contract_breach, or no_contract.
AIBOM-compatible
Complements OWASP CycloneDX ML-BOM. Model provenance + process provenance = complete audit trail. Use both standards together.
The governance chain
A Development Receipt is the final link in a five-step evidence chain. Every step produces an artefact; the receipt binds them all with a tamper-evident hash.
Commit devcontract.json
Define your quality gates and governance clauses before AI-assisted work begins.
Trigger scan
Automated on push or PR via ticketyboo-action, or manually at ticketyboo.dev/scan/.
Seven layers run
Dependency, Secret, SAST, IaC, License, Quality, and Agent Security layers evaluate the repo.
Receipt generated
Scanner maps findings to clauses, computes verdict, appends SHA-256 attestation, stores receipt.json.
Receipt accessible
Verifiable at ticketyboo.dev/api/receipt/{scan_id} — linked from every scan report page.
AIBOM vs Development Receipt
The two standards are complementary. AIBOM records what AI was used. The Development Receipt records under what governance it was used. Together they form a complete audit trail.
| Dimension | OWASP AIBOM (CycloneDX ML-BOM) | Development Receipt v1 |
|---|---|---|
| What it records | Model name, version, supplier, checksum | Governance regime active when AI produced output |
| Scope | Model inventory | Session / scan provenance |
| Standard body | OWASP / CycloneDX | ticketyboo.dev (open) |
| Format | CycloneDX JSON / XML | JSON Schema 2020-12 |
| Verification | Checksum on model artefact | SHA-256 over all receipt fields |
| Captures verdict | — | ✓ compliant / contract_breach / no_contract |
| Best used for | Software composition analysis | AI governance auditing |
| Use together? | ✓ Yes — use both | ✓ Yes — use both |
The five receipt blocks
Every Development Receipt is structured as five top-level objects. Each block has a defined schema with additionalProperties: false — no receipt inflation by downstream tools.
A complete Development Receipt
Every scan at ticketyboo.dev produces a receipt in this format. The attestation.hash is computed over the canonical JSON of all other fields — tamper-evident without any external authority.
// Development Receipt v1 — contract_breach example { "receipt_version": "1", "receipt_id": "rcpt_abc123def456", "generated_at": "2026-04-11T10:00:00Z", "subject": { "type": "repository_scan", "repo_url": "https://github.com/example/myproject", "scan_id": "abc123def456", "branch": "main" }, "agent": { "tool": "ticketyboo-scanner", "model": "claude-sonnet-4", "model_family": "claude", "session_type": "automated_scan", "scanner_version": "1.0" }, "governance": { "devcontract_id": "dc_myproject_v1", "clauses_evaluated": ["G001", "G002", "S001"], "clauses_passing": ["G001", "G002"], "clauses_failing": ["S001"], "overall_verdict": "contract_breach", "breach_severity": "high" }, "evidence": { "findings_count": 7, "critical_count": 0, "high_count": 1, "medium_count": 3, "low_count": 3, "health_score": 72, "layers_run": ["dependency", "secret", "sast", "governance"], "report_url": "https://ticketyboo.dev/r/abc123def456/" }, "attestation": { "method": "sha256-self", "hash": "sha256:a1b2c3d4e5f6789...", "verifiable_at": "https://ticketyboo.dev/api/receipt/abc123def456" } }