Skip to content
A pipeline diagram. A client spec becomes requirements and an approved scope. Capabilities dispatch into a connected Salesforce org and Marketing Cloud tenant. A verifier reads both back, and the result becomes a signed evidence pack.

Everyrequirement,proved in theclient's org.

Paste the client's spec. We build it in their org, then read the org back to prove every line.

Book a walkthrough
Scroll to explore

Delivered is notthe same as proved.

Every engagement ends with a status doc that says done — and a client who has to take your word for it.

One requirement is one node.Proof is reading every node back.

A requirement card pulls back to reveal that it is one node in a large lattice of requirements, none of which is currently proved.

The loop

How it works.

Three stacked planes. Inputs on the front plane fan through a central focus point out to outputs on the back plane, and a separate bundle of return arcs carries the verifier's read-back from the outputs to a sealed evidence chip on the input plane.

  1. Spec in

    Paste the client's spec, SOW or RFP. The platform extracts it into requirement cards you can actually read.

  2. Scope review

    Edit, reject, approve. The approved scope is what gets built — nothing else.

  3. Connect their org

    OAuth into the client's own Salesforce sandbox or Marketing Cloud tenant. Their org, their credentials.

  4. Dispatch

    Capabilities write real metadata — objects, fields, flows, permission sets, journeys, data extensions.

  5. Verify & sign

    An independent verifier reads the org back and checks the value, not just that something exists. What it can't prove stays un-green.

Proof, not assertion.

  • Green is earned, not stamped.

    A requirement turns verified only when a verifier reads the client's org and the value matches the spec. Existence is not proof.

    See how

  • It writes into the real org.

    Not a simulator, not a mock. Capabilities dispatch against the client's own sandbox or tenant.

    See how

  • One loop, two clouds.

    Salesforce core and Marketing Cloud run through the same spec-in loop, the same verifier, the same evidence pack.

    See how

What it can write.What it can prove.

58 capabilities are registered today — 50 against Salesforce core and 8 against Marketing Cloud.

Sales Cloud

Record types and business processes, provably deployed

Sales Cloud

Record types and business processes, provably deployed

Service Cloud

Case layouts, assignment rules, and the permissions to see them

Marketing Cloud

Journeys, data extensions, and the audience they actually target

Verifier

Reads the org back and compares the value, not the existence

Evidence

A signed pack your client can hold you to

Sales Cloud: Record types and business processes, provably deployed

From our own
regression runs

Pick a requirement.See what the org said.

The import definition exists in the tenant and was found by key —the run reused it instead of creating a second one.destinationName = NT_Import_Staging_Contacts, updateTypeId = 0,allowErrors = false, fileType = CSV.Read back by a separate script that trusts nothing the dispatch reported.

Verified · sfmc_automation_structure

These are runs against our own regression project, adjudicated by an independent verifier and, for the two Salesforce items, re-checked by an adversarial reviewer. We have no customer engagements to show yet.

What the platform measures.

Numbers from our own run ledger, 3 to 26 July 2026. Not customer outcomes — we have no customers yet, and we won't pretend otherwise.

  • Verifier-signed runs365Dispatch runs an independent verifier read back and signed off.Source: run ledger
  • Verifier refusals415Runs the verifier would not sign. They stayed un-green.Source: run ledger
  • No verdict recorded440Runs carrying no verifier verdict at all. Disclosed, not hidden.Source: run ledger
  • Capabilities registered58Distinct capabilities that can write metadata into a connected org.Source: capability registry
  • Clouds addressed2Salesforce core and Marketing Cloud, through one loop and one verifier.Source: capability registry

Counted 26 July 2026 over 1,220 dispatch runs. These count our own system objects and our own runs against our own connected tenants. They are not customers, not deliveries, and not outcomes.

When the client asks for proof, it starts here.

Walk one spec through with us