VIRTICUSRequest Assessment

How an automation is built

Watch a compliant automation get built — or watch a check refuse to build it.

This is the real build, running in your browser. Change the brief below and the whole automation is rebuilt instantly: requirements are re-checked, every check re-decides, and the evidence chain is rebuilt. Nothing here is a recording — the same code answers the API.

The brief

How it is built

Capturepassed

Rough asks → a coverage-checked requirement set

All required areas are covered or safely defaulted; Capture may release to Design. WITNESS: delivery is still uncaptured for this domain — it predates the requirement. It does not block, and it does not mean our console ships.

Designpassed

Requirements → fixed-version steps, then human sign-off

Approved by "Compliance Lead" on 2026-02-04 (no decision tier to bind to); design covers all confirmed compliance requirements.

Build & Deploypassed

Run the fixed-version steps, verify the built automation

Built automation passed final verification; cleared to deploy.

Handoverpassed

Evidence pack · operator docs · training brief

Delivered. Three distinct artifacts produced for three audiences.

Delivered

Every check passed. The automation was built from fixed-version steps and handed over with the evidence that proves each decision.

Capture — coverage map

Not a vanity count of how many requirements were generated. What matters is what is covered and — louder — what is not.

12

Confirmed

backed by a client ask

0

Inferred

safely defaulted

0

Unknown

gaps — never assumed safe

Design — the steps chosen

Design assembles 3 pinned blocks covering: audience-and-consent, claims-and-disclosures, brand-and-tone.

audience-consent-check@1.0.0promo-rewrite@1.0.0financial-promo-claim-check@1.0.0

Template-bound narrative — the moat

The drafting step rewrote the copy, then the deterministic control step re-checked its output. Delivery carries proof the generation stayed inside the approved bound — the deliverable no black-box builder hands over.

Draft in

Guaranteed returns, risk-free. Our new savings bond is built for long-term savers.

Delivered out

Our new savings bond is built for long-term savers. Capital at risk.

financial-promo-claim-check@1.0.0 verdict on the generated copy: pass

  • · Removed non-compliant sentence: "Guaranteed returns, risk-free."
  • · Appended required disclosure: "Capital at risk."

Evidence chain

Every step emits its own traceable record — the exact input, the decision, and why. This is what gets handed to an auditor.

step 1audience-consent-check@1.0.0control
  • · All 2 recipients have a lawful basis for email.
step 2promo-rewrite@1.0.0generative
  • · Generation bounded by financial-promo-claim-check@1.0.0; control verdict on output: pass.
  • · Approved-claim envelope: [none].
  • · Removed non-compliant sentence: "Guaranteed returns, risk-free."
  • · Appended required disclosure: "Capital at risk."
step 3financial-promo-claim-check@1.0.0control
  • · All risk-carrying phrases were approved or absent; every required disclosure present.

Lockfile — demo-campaign-11111

Fixes the exact version of every step this run used, so the run is reproducible from the lockfile alone — and so “which runs used this step?” is a query, not archaeology.

audience-consent-check@1.0.0promo-rewrite@1.0.0financial-promo-claim-check@1.0.0

Handover — three artifacts, three audiences

Operator docs

How to run it.

  • · Provide the campaign payload: recipients, copy, approved claims, required disclosures.
  • · Run the pipeline; the automation gates non-compliant sends automatically.
  • · Retain the emitted evidence pack with the campaign record.

Training brief

How to keep it defensible.

  • · Why unknown != low: unconfirmed consent/claims are gaps, never safe defaults.
  • · Why generation is bounded: every rewrite is proven against the control check.