What goes into a Quality Contract?

A Quality Contract records the feature name, its criticality, accountable owners, requirement statements with stable IDs such as SUB-004, and an evidence policy listing which requirement IDs block a release. Each requirement is mapped to real tests and versioned whenever the approved product intent changes.

How do I create and approve a Quality Contract?

Create contracts from existing requirements with maru contract create --from requirements.md, then list, show, validate, diff, and approve them from the CLI. Approval is recorded against a named owner, so a contract change always carries the identity of the person who accepted the new behavior.

How is a Quality Contract different from a test?

A contract holds the promise; the tests are one form of evidence that the promise still holds. Because an AI agent can rewrite tests and implementation together, MaruCheck keeps the approved statement in a separate reviewed file that only an accountable owner can change.

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.

Frequently asked questions

What goes into a Quality Contract?: A Quality Contract records the feature name, its criticality, accountable owners, requirement statements with stable IDs such as SUB-004, and an evidence policy listing which requirement IDs block a release. Each requirement is mapped to real tests and versioned whenever the approved product intent changes.
How do I create and approve a Quality Contract?: Create contracts from existing requirements with maru contract create --from requirements.md, then list, show, validate, diff, and approve them from the CLI. Approval is recorded against a named owner, so a contract change always carries the identity of the person who accepted the new behavior.
How is a Quality Contract different from a test?: A contract holds the promise; the tests are one form of evidence that the promise still holds. Because an AI agent can rewrite tests and implementation together, MaruCheck keeps the approved statement in a separate reviewed file that only an accountable owner can change.

Last updated August 21, 2026