SPM·STANDARDS
INSTITUTE

FIELD EVIDENCE / REFERENCE IMPLEMENTATION

A protocol shaped
by doing the work.

The founding field work provides a proof of concept: human operators coordinating named AI orchestrators to build and operate a real service.

Field note · 18 October 2026

WHY THIS IS RELEVANT

Work produces claims.
Verification produces confidence.

The reference work demonstrates how a shared operating record makes coordination, corrections and unresolved obligations visible.

The team used SPM while building a live website, client onboarding, payment and invoice integration, a shared message bus, and a service-accounting ledger with an operational mirror.

The evidence supports a bounded implementation case. Broader claims about repeatability, scale and independent professional certification require their own evaluation.

CONTINUITY ACROSS ORCHESTRATORS

One record.
Many hands.

The continuity illustration shows the idea: roles and the working record carried from one orchestrator to the next.

Conceptual illustration: AI orchestrator characters in a broad, flat courtyard with an SPM knowledge console to one side, showing roles and the working record carried across orchestrators.

Conceptual illustration. It is not proof of every pictured integration. What works depends on the environment and the permissions each AI is given.

CASE NOTE 01

Continuity across
orchestrators and engines.

Field implementation

Working context and decisions moved from document journals to a shared bus. Explicit handoffs and versioned protocol records support recovery when an orchestrator changes execution context.

What the evidence establishes

Recorded exchanges, relocation acknowledgements and adopted version pointers demonstrate use of the shared-record workflow. Each relocation still requires its own identity, context and authority checks.

CASE NOTE 02

Service accounting
with a causal record.

Live-path evidence

The team connected payment records, TAC book entries, grants, pool transfers and settled usage to a mirrored operational record. Reconciliation exposed missing events and duplicate legacy handling.

What the evidence establishes

The initial source batch contained 24 event records representing 15 business transactions. Team reports subsequently reconciled funding and usage, with explicit source watermarks. This is evidence for register-based accounting; an on-chain deployment is a separate milestone.

CASE NOTE 03

Recovery that keeps
the unresolved work visible.

Controlled tests & reported findings

The team tested retries, restarts, lost acknowledgements and rebuilds against isolated projections. Customer input versions were linked to a preserved execution/result in a marked fixture.

What remains to verify

Reported tests cover each adapter with a stand-in for the other side. Independent combined-adapter checks and live customer-producer hooks remain explicit residual work. A test result is attributed to its method and author.

WORKED CYCLES

From claim
to inspectable cycle.

Short case notes describe what the team did. The worked cycles take a bounded task from objective to result, with the deviation, the correction and the limits stated. They are in preparation.

See the structure →

HOW TO READ THE EVIDENCE

Every claim
has a boundary.

We distinguish working implementation, controlled tests and independent verification in the record.

REPORTED

Attributable claims.

The responsible participant describes the result, scope, revision and evidence.

TESTED

A reproducible method.

The environment, inputs, observations and limitations travel with the result.

VERIFIED

An explicit check.

A reviewer checks the consequential claim against inspectable evidence and records a disposition.

CODING AUTOMATION · THE CLAIM

One claim.
Stated and attested.

The founders state that AI orchestrators write the implementation code while people direct the work, and they put their names to it.

On this project the code is written by AI orchestrators under human direction. The people who run it write none of it.

Status
Attested by the founders, by name. The basis is the operating record kept for the whole build.
Who attests
Dan, a systems analyst since 2008 who has written code since 2001, and David. On this project neither of them writes code.
How the work runs
The operator speaks. An AI orchestrator writes, tests and records the change. People set the direction, decide, approve and verify the result.
The record
Every task, decision and handover is written to one shared operating record. That record is what lets a different orchestrator pick the work up and continue it.
Independent check
No outside audit of the record has been made yet. The Institute will publish how such a check is done.
Limits
This describes automation of coding under human direction. It is not a claim of autonomous business operation, of all code ever used, of universal reliability or of support for every provider.

FOR ORGANIZATIONS

Inspect the method.
Then test it in your context.

Start with a bounded management task and explicit acceptance criteria. A pilot should retain evidence, surface failures and give the organization enough information to make its own adoption decision.

Create your Zero ↗