Core concept

Quality Contracts

A Quality Contract is the durable boundary between what people approved and what an implementation happens to do today.

What belongs in a contract

Behavior that must remain true across refactors
Authorization and ownership boundaries
Limits, retries, expiry, and failure behavior
Observable acceptance criteria

Version 1 structure

version: 1
id: invoice-access
title: Invoice Access
status: draft
criticality: critical
intent: Keep invoice reads inside the authenticated organization.
owners:
  - billing
requirements:
  - id: INV-001
    statement: A user can only read invoices owned by their organization.
    priority: required
invariants:
  - id: INV-INV-001
    statement: A client-supplied organization ID never grants invoice access.
edge_cases:
  - a user guesses an invoice ID from another organization
security:
  - enforce organization ownership on the server
data_integrity:
  - preserve the invoice organization relationship
evidence_policy:
  blocking_requirements:
    - INV-001
    - INV-INV-001

This uses the current version 1 schema. Create contracts through the CLI when possible so validation and review prompts are applied consistently.

Review rules

Give every requirement a stable identity.
Make the expected behavior observable.
Call out security and data boundaries explicitly.
Approve contract changes separately from incidental code changes.
Keep a contract in draft or review until its proposed blocking policy is ready to gate releases.