Enspirit Delivery OSUnder the hood

How a change moves.

The technical detail behind Enspirit Delivery OS, for the engineers who will run it: the seven-step run, the eight agents and what each is not allowed to do, the release hold, and the record it leaves in your repository.

The run

One command, in the repo you already have open.

Each phase hands the next a finished artifact. Eight checks run in parallel and flag; three human checkpoints decide: architecture review before code exists, code review before the pull request opens, and the QA verdict before anything ships.

  1. 01FoundationProject context
  2. 02RefineValidated brief
  3. 03SpecifyVerifiable spec
  4. 04PlanExecutable planArchitecture review
  5. 05BuildWorking code, testsCode review
  6. 06VerifyVerified criteriaQA verdict
  7. 07ShipLive and healthy
Shipped product

What shipped feeds the next brief

  • Rules versioned and reviewed like code, applied before a commit exists.
  • Every decision lands in your repo as a file: the audit trail is a by-product of the work.
  • Each phase hands the next a finished artifact, and Surveyor produces the signals AURA, the release confidence platform, scores at the end.

The crew

Eight agents, led by what they cannot do.

Every agent platform will tell you what its agents can do. The part that makes the output trustworthy is the boundary. Each member of the crew has a fixed job and a fixed limit, enforced by the rules in your repository.

Lookout

LKTresearcher

Gathers source material and prior art, reports what is ahead.

Does not decide.

Navigator

NAVplanner

Decomposes work into tickets and sequence, sets the course.

Does not build.

Sparks

SPKwriter

Drafts prose, posts, docs, and copy.

Does not touch application code.

Shipwright

WRTbuilder

Writes and changes code, writes unit tests.

Cannot skip tests. Escalates on schema changes, dependency bumps, and anything genuinely ambiguous rather than guessing.

Auditor

AUDreviewer

Reads the diff against the rules and a security checklist, describes exactly what must change.

No write access. It cannot change anything it finds.

Surveyor

SVYverifier

Runs the suite, checks the stage deploy, produces pass or hold.

Cannot write application code, cannot merge.

Dispatcher

DSPpublisher

Promotes stage to production, confirms live.

Never merges on its own.

Archivist

ARCanalyst

Reads the record and reports what moved.

Writes nothing back.

Enspirit Delivery OS itself is the orchestrator, and none of the eight leads the others. Tenet, the design governance plugin for Figma, applies the same idea to design.

Airlock and Deck

Before a release, every station reports.

Airlock is the mechanism that holds work. Not an agent, not a person. Before anything ships, every station reports go or no-go. Any single station can call a hold, and nothing proceeds until it clears.

Surveyor operates the Airlock and is the only member of the crew who can hold a release. The poll is on the record.

The record is the dashboard

Deck is the read-only client view over the plain-text records in the governance repository. No database, no login, no server-side state; it generates the meeting deck from the same facts it displays, so the two cannot disagree. Delete the directory and every record still stands, because the records are files in your repository.

See it on one of your workstreams.

The first four weeks: fixed scope, fixed fee, measured against your own Jira and Git history. If your cycle time does not move, you do not pay for it.

Start with four weeksSee the four-week terms