Skip to content

FAQ

Common questions about DevContract — its scope, enforcement model, enterprise use, and integration with the rest of the ticketyboo platform.

Concept and scope

Is a DevContract legally binding?

No. A DevContract is a technical governance document — a machine-readable specification of constraints and acceptance criteria for an AI-assisted engagement. It is not a legal contract between organisations. For legal agreements, you still need your standard professional services contracts, NDAs, and procurement processes. DevContract provides the governance layer that sits inside those legal agreements.

Does Claude actually understand and enforce the contract?

Claude reads the contract block at session start and works under its terms because the contract is presented as binding instructions in the system prompt — the same layer where role definitions and operating constraints live. Claude does not have a contract enforcement runtime that independently validates every action. The enforcement chain is: contract in system prompt → Claude consults it for material decisions → Gatekeep scans at PR time → evidence bundle produced.

This is the same model as any professional engagement: the contractor reads the SOW, commits to working under it, and the client verifies compliance at delivery. Neither party has a robot enforcer watching every keystroke.

What if Claude ignores a contract clause?

Gatekeep catches most violations at PR time via the scan gates. Clause violations that scan gates cannot detect (e.g. architectural pattern violations not expressible as scan findings) require code review. The DevContract is a governance layer, not a guarantee. It dramatically reduces the surface area of non-compliant AI output, but it does not eliminate the need for human review on material decisions.

Can I have different contracts for different repositories?

Yes. Each repository has its own .tickety/devcontract.json. A regulated SaaS product and a scratch prototype can have completely different contracts. The contract is per-project, committed to the repository, and version-controlled alongside the code.

Enforcement and delivery

What is the relationship between DevContract and Gatekeep?

They are complementary:

  • DevContract (pre-execution): governs the AI session before and during execution. Sets the terms. Injected into the system prompt.
  • Gatekeep (post-execution): scans the deliverable at PR time and evaluates it against definition_of_done.scan_gates. Produces the evidence bundle.

A project can use Gatekeep without a DevContract (scan-only governance). A project can have a DevContract without Gatekeep being installed (contract governs the session but no automated scan at PR time). Full value comes from both working together.

What happens if a blocking scan gate fails?

The evidence bundle records the violation with overall_verdict: contract_breached. If audit.pr_comment_required is true, a summary with the violations is posted as a PR comment. The PR should not merge until the violations are remediated and the evidence bundle shows contract_fulfilled.

Can I waive a clause for a specific session?

The clean way to do this is to use approved_exceptions in the cost clause or threshold in scan gates for known compromises. Ad-hoc clause waiving during a session is not supported — the contract is loaded fresh at session start and applies in full. If you need to change terms, edit the contract file and commit the change with a clear rationale in the commit message.

Integration

Can I use DevContract without the tickety-ai VS Code extension?

Yes, with a manual step. Copy the rendered contract block from your devcontract.json using renderContract() and paste it as the first block of your system prompt (or .clinerules file) manually. tickety-ai automates this injection, but the contract block is just text — any AI assistant can read it.

Does DevContract work with AI assistants other than Claude?

The contract block rendered by renderContract() is plain text and works with any system-prompt-aware AI assistant (GPT-4o, Gemini, Mistral, etc.). The evidence bundle generation and Gatekeep integration are Python-based and not model-specific. tickety-ai currently targets Claude, but the contract model is intentionally model-agnostic.

How does DevContract relate to .clinerules?

.clinerules is a prose proto-contract — a free-text file that tells the AI what it can and cannot do in your codebase. DevContract formalises that prose into a structured, machine-readable schema with a defined enforcement model and a signed evidence receipt.

You can have both. When tickety-ai injects the contract, it prepends the contract block before the steering .md files. If your .clinerules content is in .tickety/steering/, it follows the contract in the system prompt — reinforcing the contract terms rather than replacing them.

Enterprise

Can I use DevContract across a team of AI developers?

Yes. Commit the contract to the repository. Every team member's tickety-ai session will load the same contract. Contract changes go through normal PR review — the commit history provides an audit trail of when terms changed. For enterprise use, consider requiring PR approval from a named contract owner for changes to .tickety/devcontract.json.

Is the evidence bundle suitable for ISO 27001 audit evidence?

The evidence bundle is a structured record of governance decisions made during an AI-assisted engagement, signed against the contract hash. Whether it satisfies specific ISO 27001 audit requirements depends on your ISMS, your auditor, and what specific controls the evidence is supporting. The iso27001_enterprise archetype sets 7-year retention and requires evidence_signed: true — a good baseline for regulated environments. Engage your DPO and auditor to confirm what additional documentation is required.

Can I have multiple contracts in one repository?

A single .tickety/devcontract.json governs all sessions in that project. If your monorepo has services with different compliance requirements, consider splitting them into separate repositories each with their own contract, or using a shared contract that represents the strictest applicable standard across all services.