Philosophy

Stoney is built on a simple principle:

Requirements and implementation must never drift.

In most organizations:

• Requirements live in tickets
• Tests live in code
• CI checks live somewhere else
• Documentation drifts silently

Over time, intent and reality diverge.

Stoney closes that gap.

Requirements as Code

Stoney treats requirements as executable artifacts.

A contract is not a test suite. It is a declaration of system invariants.

Example:

work_item: "KAN-42"
says: "Login must succeed with valid credentials"

When Stoney runs in CI:

• Failures are mapped to invariant IDs
• PRs surface intent via says + work_item
• CI enforces a Definition of Done based on guarantees, not hope

Intent becomes enforceable.

Declarative Integrity

Traditional CI answers:

“Did the tests pass?”

Stoney answers:

“Is the system still in contract?”

Contracts define:

• What must always be true
• What must never drift
• What must exist before merge

If a contract fails, the change does not ship.

No silent regressions. No guesswork.

Deep Subset Matching

Most API tests are brittle.

If a response adds a new field, the test fails — even if nothing broke.

Stoney uses Deep Subset Matching.

You assert only the fields that matter.

If your API returns:

{
  "ok": true,
  "version": "1.2.3",
  "region": "us-east-1"
}

And your contract specifies:

json:
  ok: true

The contract passes.

Extra fields are allowed.

Contracts remain stable as systems evolve.

Safe-by-Default Infrastructure

Database checks are powerful — and dangerous if misused.

Stoney protects infrastructure by default:

• Write queries (INSERT, UPDATE, DELETE, DROP) are blocked
• Multi-statement SQL is blocked
• statement_timeout is enforced per query
• Connection strings are never stored in contracts (use url_env)

Contracts are read-only by default.

Living Audit Trail

By linking checks to work items and documentation, Stoney creates a traceable chain:

Work Item → Contract → CI Enforcement → Deployment

Every merge answers:

• What requirement did this satisfy?
• What invariant did it change?
• What system guarantees were verified?

Why Stoney Exists

Teams move fast. Drift happens quietly.

Stoney exists to make drift visible and enforce intent automatically.

If it’s not in the contract, it doesn’t exist in production.

That is Requirements-as-Code.