Proofload

The Proofload Method: constrained-context delivery with stateless AI agents.

Proof loading is the certification practice of applying loads beyond operating levels to qualify a part before it enters service. Proofload borrows the stress-testing discipline, not the certification claim. It is not formal proof or compliance certification; it is an evidence and gate system for reducing claim drift in AI-agent delivery.

This is not a prompt collection. It is a staged delivery system: business domain first, architecture next, stack after that, then node and slice specifications, pressure tests, diagrams, gates, implementation, review, and re-review.

Paper

The citable preprint is archived at Zenodo: The Proofload Method: Constrained-Context Delivery with Stateless AI Agents. Citation metadata is provided in CITATION.cff.

Scope

The method is extracted from one confidential greenfield build and one public library refounding. Its spine is domain-neutral; project-specific vocabulary lives in opt-in profiles under templates/profiles/. Current evidence is limited to feasibility for:

• greenfield systems;
• clean-room refounding of a well-bounded library or API surface;
• a well-understood business process whose truth can be extracted from real materials and operating experts;
• one human orchestrator directing role-separated AI agents from spec through build and review.

The worked example exercises two profiles: the event-driven profile (queues, workers, transactional outbox, consumer inboxes, cross-boundary consistency; see templates/profiles/event-driven.md) and the financial-compliance profile (retention, erasure, and audit as first-class behavior; see templates/profiles/financial-compliance.md). Those are profile capabilities, not core scope.

Outside the observed envelope, apply judgment before applying the method:

• production operation and load behavior are not yet evaluated;
• gate authority under CI, multi-human teams, and brownfield adoption are untested;
• domains without an established business process, such as product discovery and exploratory prototypes, violate the domain-extraction premise;
• the current evidence is limited to a small number of stacks and delivery shapes.

Do not use the full version for simple CRUD apps, prototypes, static sites, single-process utilities, or low-risk UI exploration. Use a lighter version there.

The Sequence

Run the project in this order:

1. Business domain documentation.
2. Architecture principles and high-level system choices.
3. Stack selection and runtime contracts.
4. Master node map and dependency diagram.
5. Node specification process.
6. Slice contracts.
7. Node specs and node diagrams.
8. Pressure tests and Gate X consistency.
9. Implementation handoff.
10. Deterministic and integration gates.
11. Independent review on every non-trivial commit.
12. Re-review after fixes.
13. Fold learnings into the next slice.

Do not start with the stack. Do not start with tickets. Do not ask an agent to "build the app".

Folder Contents

• runbook.md - phase-by-phase replay checklist with artifact dependencies.
• workflow.md - the end-to-end build process.
• gates.md - the quality gates and exit criteria.
• agent-runs.md - how to run implementers and reviewers.
• templates/ - copyable project artifacts.
• templates/profiles/ - opt-in overlays that add domain- or architecture-specific sections and vocabulary; see templates/profiles/README.md.
• examples/returns/ - a fictional returns-and-refunds platform taken through phases 0 to 9; start here to see the method end to end.
• tools/proofload_check.py - reference consistency checker, the mechanical part of Gate X; runs green against the example.
• tools/mutation_test.py - exercises every checker class with a targeted mutation; a gate that cannot fail is decoration.

Operating Rule

Every claim becomes one of:

• a domain reference;
• an architecture decision;
• a stack/runtime decision;
• a node contract;
• a slice contract;
• an acceptance criterion;
• a test;
• a pressure-test finding;
• a status-ledger entry.

Claims that remain prose are not stable enough for agents to build from.

Minimal Artifact Set

Create these before serious implementation:

• docs/domain-reference.md
• docs/architecture-principles.md
• docs/system-overview.md
• docs/runtime-contracts.md
• STACK.md
• STATUS.md
• NODE_PROCESS.md
• specs/NODE_SPEC_TEMPLATE.md
• pressure-tests/PRESSURE_TEST_TEMPLATE.md
• diagrams/master-node-map.mmd
• specs/slice-1-contracts.md
• specs/slice-1-event-port-map.md (event-driven profile only).

docs/runtime-contracts.md here means the core runtime contracts (timeouts and cancellation, structured errors, secrets and rotation, resource bounds, failure-surface). Queue, outbox, and operator-item contracts are added only when the event-driven profile is active.

Then repeat slice by slice.

Core Pattern

Business truth is extracted first. Architecture constrains it. Stack supports it. Specs encode it. Gates verify it. Agents implement inside it.

That ordering is the method.

License

Repository materials are released under the Apache-2.0 license. The Zenodo preprint record is released under CC-BY-4.0.