DevContract
You already contract your development houses. You should contract your AI developers the same way. A DevContract is a machine-readable Statement of Work placed at .tickety/devcontract.json. The AI reads it at session start, works under it throughout, and produces a signed evidence receipt at delivery.
Three phases
Every DevContract engagement follows three phases:
Phase 1
Contract
You define devcontract.json. The AI reads it at session start via tickety-ai and explicitly acknowledges the terms before any work begins. The contract is the first thing in the system prompt.
Phase 2
Execution
The AI queries the contract on every material decision — stack choice, infrastructure, secrets handling, patterns. Each query, verdict, and action is logged in the evidence ledger.
Phase 3
Delivery
Gatekeep evaluates the definition_of_done clause. The evidence bundle is assembled, each clause is assessed pass/fail, and a signed receipt is produced — tied to the specific contract hash.
Eight clause families
A DevContract is not a list of scan gates. It is a structured SOW with eight clause families, each covering a different dimension of the engagement:
| Clause | What it governs | Example constraint |
|---|---|---|
stack |
Language, runtime, cloud region | Python 3.12 · aws_lambda · eu-north-1 |
architecture |
Required and forbidden patterns | single_table_dynamodb · no fat_handler |
cost |
Budget envelope, forbidden resources | aws_free_tier · no nat_gateway |
security |
Auth mechanism, secrets store | cognito_jwt · ssm_parameter_store only |
quality |
Type hints, coverage, logging | type_hints: required · coverage ≥ 80% |
compliance |
Regulatory frameworks, data handling | GDPR · hard_delete_only · eu_only |
audit |
Evidence requirements, signing | evidence_signed: true · 7 year retention |
definition_of_done |
Acceptance criteria including scan gates | tests_pass + coverage_met + scan gates |
The scan gates that were previously the entire contract now live inside definition_of_done.scan_gates — their correct home as one part of a proper acceptance gate.
How it works end-to-end
- Place
.tickety/devcontract.jsonin your project root. - tickety-ai reads it at session start and injects it as the first block of the system prompt — before any steering files.
- Claude acknowledges the contract, then works under its terms for the session.
- At PR time, Gatekeep evaluates the
definition_of_doneclause against its scan findings. - An
evidence.jsonis produced, clause by clause, and signed against the contract hash. - Violations are structured with the exact clause breached, evidence reference, severity, and remediation required.
In this section
Concept
What is a Contract?
The contractor analogy. Why pre-execution beats post-execution. How DevContract differs from a CI gate config.
Reference
Schema reference
Complete field-by-field reference for all eight clause families in devcontract.json.
Reference
Archetypes
Three ready-made contracts: free-tier Python, GDPR SaaS, and ISO 27001 enterprise.
How-to
Writing contracts
Start from an archetype, write by hand, or generate from Stack mode.
How-to
Agent injection
How tickety-ai reads devcontract.json and injects it into the system prompt at session start.
Reference
Evidence bundle
What goes into the signed evidence receipt. What auditors, clients, and regulators receive.
Reference
Violations
The ContractViolation model. How violations are cited, structured, and remediated.
Reference
Scan gates
Gatekeep gate categories, severity levels, and thresholds within definition_of_done.
Demo
Live demo
See a contract rendered as a steering block, queries answered, and an evidence bundle produced.
FAQ
FAQ
Common questions about DevContract: scope, enforcement, enterprise use, and integration.