SURETY / FIELD GUIDEEngineering ↗
INSIDE THE PLATFORM · INTERACTIVE CONCEPT

From an idea.
To software.
With proof.

A team of AI roles creates the software.
Surety governs what happens next.

Follow a project from its first conversation to a running app. See who acts, what must be proven, and what the engine remembers.

Take the guided tour ↘
Accepted M1–M4M5 implementationM6 designFuture
Source snapshot · 16 October 2026 · ded5d5a
Educational simulation. No connection to your engine.
Want to know HOW it works?Trace plans, agent calls, isolation, teardown and human authority through the code →
01 / FOLLOW THE WORK

One platform. Three ways in.

Meet Fieldwork, an illustrative appointment app.
Choose how its story begins.

DELIVERY LANDSCAPENEW APPLICATION
Moving light = this illustrative projectClick a station to explore

02 / BENEATH THE JOURNEY

The agents do jobs.
The engine holds the rules.

The engine is a durable coordinator. It assigns work, limits authority, collects evidence and stops when a rule cannot be satisfied.

SURETY ENGINEObserve.
Decide.
Record.Repeat safely ↻
◎Owner

Approves intent and decisions that need human authority.

⌘Builder

Changes application code. Cannot quietly rewrite the acceptance rules.

✓Verifier & Reviewer

Create checks, assess evidence and challenge the result. Review depends on scope and tier.

↗ReleaseOperator

Deploys through scoped authority. Cannot waive a failed check.

↺ What if the engine crashes halfway through?

It reads its durable records and reconciles work already in flight before admitting new work. An intent is recorded before a git or deployment effect; recovery examines what actually happened before completing or retrying it.

A stopped conversation is not proof that its process stopped. Uncertain ownership or effects remain unresolved; quarantine prevents work from being treated as safely complete. Budgets and usage records survive the restart too.

D1 §§7, 8, 13, 16; D2 containment; D4 recovery. This diagram simplifies the scheduling order.
03 / TRY TO OPEN A GATE

“The agent says it works”
doesn’t open the gate.

A gate is a rule evaluation over recorded evidence. Change the demonstration inputs and see why work proceeds—or stops.

×

    Teaching model, not the full gate implementation.
    Approval never turns a failed, missing, stale or skipped required check into a pass.

    Running ≠ verified.

    The environment keeps three facts separate.

    01 · EXPECTEDWhat should be there?

    The authorized candidate and configuration.

    02 · OBSERVEDWhat is actually there?

    Read identity and condition, with observation time.

    03 · VERIFIEDWhat was proven?

    Applicable behavioural checks on that deployment.

    D1 §9 (as amended); D3 §§1–2; D4 §§3–5; D6 §§5–6. The applicable gate rules also include tier, policy, version bindings and scope-specific conditions omitted from this demonstration.

    04 / THE PLATFORM’S MEMORY

    Software has versions.
    So does the evidence.

    Git keeps the project’s files. SQLite keeps the engine’s durable state. Records keep the supporting evidence. Each has a different job.

    GITThe work itself

    Source, approved specifications, architecture and protected checks.

    SQLITE · DURABLE STOREWhat the engine knows

    Identity, work, decisions, evidence bindings, deployments and usage.

    RECORD STOREThe supporting material

    Transcripts, outputs and evidence records, with redaction and retention.

    ONE DURABLE SQLITE STOREOutside the project checkout · survives branch changes

    Conceptual grouping of actual tables; not an exhaustive relationship diagram.

    FOLLOW ONE PIECE OF EVIDENCE · ILLUSTRATIVE IDS

    Requirement→Stage & candidate→Check result→Gate evaluation→Deployment verification

    Change the relevant source, specification or protected checks, and old evidence may become stale. A green result is meaningful only with its bindings.

    05 / THE WHOLE PLATFORM

    Alpha is a milestone.
    Production is the larger promise.

    The vision includes deployment, operation and feedback. The map below keeps that ambition visible without presenting future adapters as built.

    ACCEPTED · M1–M4

    A controlled foundation

    Durable engine, isolated agents, protected checks and verified local Alpha deployment.

    M5 · IMPLEMENTED / VALIDATING

    Idea to Alpha

    Conversations, specifications, phase planning, autonomous work and existing-repository adoption.

    M6 · DESIGN DEFINED

    A design partner

    Interface inventory, mockups, feedback, design criteria and versioned brand assets.

    FUTURE · D5 / LATER

    Release, operate, learn

    Beta and Live, production destinations, operational feedback and the Mechanic.

    THE INTENDED LONG-TERM LOOPIdea → Build → Deploy → Observe → Improve ↺

    AWS · GCP · Azure · Kubernetes · local infrastructure
    Illustrative future destinations, not a supported-adapter list.

    LATER / OBSERVABILITY

    Signals become evidence.

    Operational monitoring and user feedback should produce actionable findings. eBPF is a proposed host-observation integration; it is not an implemented monitoring layer or a substitute for acceptance checks.

    Designing for a platform is different from running on it.

    D7 covers web, Android, iOS, macOS, Windows and Linux designs. M6’s non-web previews are labelled simulations. Native builds, packaging and device testing remain later capabilities.

    Source notes, status and how to read this mockup +

    What this is

    A browser-only learning experience built from repository documents at ded5d5a, 16 October 2026. Fieldwork, its IDs, gate inputs and animations are fictional teaching examples. No models run, no engine APIs are called, and no deployments are performed by this page.

    M1–M4 acceptance is recorded in CLAUDE.md and the M5 specification. M5 has implementation and real-run evidence; its acceptance report still contains pending fields. D7 draft 3 has its questions decided, but explicitly remains unadopted M6 scope. This is a snapshot, not a live progress dashboard.

    Repository references

    • docs/design/sdlc-design-D1-engine-core.md §§5–16, with resolution note and errata.
    • docs/design/sdlc-design-D2-backends-and-isolation.md — role and execution boundaries.
    • docs/design/sdlc-design-D3-checks.md §§1–2 — protected checks and evidence.
    • docs/design/sdlc-design-D4-deployment.md §§3–5 — local deployment and verification.
    • docs/design/sdlc-design-D6-idea-to-alpha.md §§1–8 — journeys and adoption.
    • docs/design/sdlc-design-D7-designer.md §§1, 5–10, 15 — Designer and platform limits.
    • packages/engine/migrations/0001–0030 — actual table families, grouped here for teaching.
    • docs/spec/M5-build-spec.md §1; docs/acceptance/reports/M5-report.md — acceptance distinction.

    Visual renderer: Three.js r170, bundled locally under its MIT license. No analytics.