Live proofs

Evidence from real executions — not just design claims. This page shows the system running on real requests and records what happened at each step. A workflow is not called successful just because it produced an output: each stage is checked, and the run records whether the work passed, stopped, or was returned for rework. The evidence is captured at execution time and pinned to the exact catalogue version used.

10Live workflow executions

9Completed end to end

1Stopped by a quality gate

Failures are designed to stop or be recorded, rather than silently propagate.

The point is simple — make AI work something that can be checked, not something that has to be trusted on appearance alone. So this page quotes the machine's own words verbatim, status codes included: no code is left unexplained, and none is softened into something friendlier — the prose and the trace use the same word, or neither is worth checking. Outputs and per-step verdicts are kept in the repository under docs/audit/live-runs/.

Proven runs

What these prove: that these processes run on real input — and that when a quality gate says no, the work stops instead of shipping.

A gate is a pass-or-stop checkpoint sitting between two stages: the work only moves on if it meets the criteria written for that stage, and nobody can wave it through. Two words carry the verdicts below: completed (every stage ran and passed its check) and returned (a gate refused the work and sent it back).

Workflow	Business outcome	Steps	Status	Result
WF-001	AI product scoping	3	completed	3 / 3 passed
WF-002	SAFe agile delivery	5	completed	5 / 5 passed
WF-003	AI application launch	7	completed	7 / 7 passed
WF-004	AI consulting engagement	6	completed	6 / 6 passed
WF-005	Strategic intelligence & growth	3	completed	3 / 3 passed
WF-006	Pre-sales / commercial proposal	6	completed	6 / 6 passed
WF-007	Mission onboarding	4	completed	4 / 4 passed
WF-008	AI Act / GDPR audit	7	⟲ returned	6 / 7 passed
WF-009	IT / AI recruitment	6	completed	6 / 6 passed
WF-010	Project post-mortem	4	completed	4 / 4 passed

Nine of the ten ran end to end and passed every check. The tenth, WF-008, was stopped by its own quality gate before it could issue its report. All ten have now run live — nine completed, one returned.

A system also has to know when to stop

WF-008 — the AI Act / GDPR compliance audit — was run live but did not clear its final quality check. Six of its seven steps passed; the counter-review gate then returned the audit for rework, so the report step was withheld. This is not treated as a system failure — it is the system doing what it was designed to do: refusing to pass work that did not meet the required criteria. It is kept on the same footing as the nine that completed, because a gate that can block a deliverable, instead of waving it through, is the harder thing to prove. Full trace in WF-008 below.

WF-009 is shown with the same care. It completed on a supplied, fictional candidate pool, not autonomous sourcing, and it carries a second trace where the same gate stopped a variant that had no candidates. One gate saying yes in one run and no in the other is what shows it actually discriminates.

Each run is pinned to the exact catalogue version it used, stated in that run's own section below.

Above these ten sits the dispatcher (WF-000, new in v0.9.0) — a router that picks which workflow to run. Its runs are a different kind of evidence, below.

WF-000 — Dispatch (router + pilot)

A business request does not automatically become a workflow. Before work starts, the dispatcher checks whether the request is actually ready — whether it matches an available process, and whether the information that process needs is present — rather than forcing it into the nearest-looking one.

What this one proves: that the system picks the right process for an incoming request — and refuses the request when it cannot. Before any of the ten processes runs, something has to decide which one. That is the dispatcher (WF-000, new in runtime v0.9.0): it reads a request written in ordinary prose, then routes it, declines it, or hands it back for missing information. It is a router, not an eleventh process — so it is not counted among the ten runs or the nine proofs.

flowchart LR
  BRIEF["Free-form brief"] --> R{"WF-000<br/>dispatcher"}
  R -- "no fit" --> NM["NO_MATCH<br/>nearest miss named"]
  R -- "underspecified" --> PM["PARAMS_MISSING<br/>names what it needs"]
  PM -- "human amends" --> R
  R -- "match" --> WF["ROUTED<br/>runs its eval-gates"]

flowchart TB
  BRIEF["Free-form brief"] --> R{"WF-000<br/>dispatcher"}
  R --> NM["NO_MATCH<br/>nearest miss named"]
  R --> PM["PARAMS_MISSING<br/>names what it needs"]
  PM --> R
  R --> WF["ROUTED<br/>runs its eval-gates"]
  NM ~~~ PM ~~~ WF

Routing accuracy — 19 out of 20. Twenty test requests were submitted; nineteen reached the process a person would have chosen. The twentieth is the interesting one: a prospect asked for a commercial proposal without having issued a tender. The deliverable matched the pre-sales process (WF-006), but that process starts from a received tender, and this request had none — so the system answered NO_MATCH (no process fits this request) and named the one it came closest to. Forcing the fit would have produced a proposal built on a stage that never happened.

Verbatim from docs/audit/live-runs/wf-000-router-live-result.json:

{
  "score": "19/20",
  "results": [
    {
      "id": "P11",
      "expected": "WF-006",
      "got": "NO_MATCH",
      "match": false,
      "detail": {
        "status": "NO_MATCH",
        "rationale": "Current state is a direct pre-signature solicitation with explicitly no RFP received, so while the expected deliverable (commercial proposal) matches WF-006's endpoint, its entry state 'RFP received' is not met and no other workflow starts from an unsigned prospect ask.",
        "nearestMiss": "WF-006"
      }
    }
  ]
}

(19 matching results omitted; the single divergence is shown in full.)

One request, end to end: refused, corrected, then delivered. Given an under-specified request the dispatcher returned PARAMS_MISSING (the request is missing facts the process needs) and named what it needed rather than guessing. A person amended it; only then did it route to WF-001 with a plan, and WF-001 ran to completed (3 / 3, catalog v4.2.0).

Excerpt (the return-loop phase) from docs/audit/live-runs/wf-000-pilot-p01-dispatch-live-result.json:

{
  "phase": "unamended (return loop)",
  "outcome": {
    "status": "PARAMS_MISSING",
    "route": "WF-001",
    "missingParams": ["team_size", "project_method", "level_of_detail"]
  }
}

Amended, it routed with a plan; the routed WF-001 run (wf-000-pilot-p01-wf001-live-result.json) then completed:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-BUSINESS-ANALYST", "catalogTag": "v4.2.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-PO-SCRUM",         "catalogTag": "v4.2.0", "verdict": "pass" },
    { "stepId": "STEP-04", "assetId": "AGENT-QA-AGILE",         "catalogTag": "v4.2.0", "verdict": "pass" }
  ]
}

Every trace on this page has that shape, so it is worth reading once. Four words carry it.

A step (STEP-01, STEP-03, STEP-04) is one stage of the process. The numbers were fixed when the process was designed, and the gaps are deliberate: a stage that did not run stays visible as missing rather than being renumbered out of sight.
An agent (AGENT-PO-SCRUM and the others) is who did that stage. The names read as the role a person would hold — product owner, business analyst, auditor.
The verdict is the quality check's answer on the work that stage produced: pass or fail. It judges the deliverable, not the agent.
catalogTag records which version of the catalogue the stage used. It is what lets anyone re-open a run against the very same assets it ran on, months later.

The excerpts below are all trimmed the same way: each stage's results and output are left out here for readability, and are complete in the source files.

Parameter checks — from one workflow to all ten (new in `v0.10.0`)

What this one proves: that the system does not start work until the information needed to deliver it is actually there — and that it asks for what is missing in business language, not in field names.

Hand it a half-formed brief and it does not improvise. It stops, names exactly what is missing — Team size, Project method, Level of detail — and asks for it. Someone answers those three lines, and the work begins. The wording comes from the process's own description sheet, not from internal field names. (The trace above was recorded on 2026-07-19, when the questions still came back as team_size and project_method; since v0.10.0 they come back in the words of the business.)

Since v0.13.0 a trace shows it rather than explaining it. A second live run took a different request — a signed consulting engagement, routed to WF-004, not the pilot's process — through the same loop. The refusal came back in the description sheet's own wording:

{
  "phase": "unamended (return loop)",
  "outcome": {
    "status": "PARAMS_MISSING",
    "route": "WF-004",
    "missingParams": ["Engagement duration", "Client AI maturity"]
  }
}

Two facts named, in the words a client would use. The request was amended and then routed to WF-004 with a plan, and the run stopped there — the decision to launch stays with a person. Verbatim from docs/audit/live-runs/wf-000-p04-dispatch-live-result.json.

▫ What this second run adds, precisely: the loop holds on a process other than the pilot. It is one more path through the same code, not a claim about all ten — and the wording change itself dates from v0.10.0, visible on any run since.

This is the most valuable behaviour in the system, and the least spectacular. The alternative is an assistant that quietly fills the gaps itself and returns something fluent, complete-looking, and built on facts nobody ever supplied. In a professional setting that is not a cosmetic problem: it means recommendations resting on invented constraints, requirements misread, rework paid for twice, and trust spent. That is the version that survives a demo and fails a client.

This system does the opposite: where information is missing it asks, and where a workflow cannot check, the record carries paramsChecked: false — nobody verified this one — rather than a silence a reader would take for a yes. NO_MATCH and PARAMS_MISSING are not failures either: they are the system declining to guess, and they are the reason the nineteen requests it did route, and the run it delivered, are worth anything.

All ten processes behave this way. What that buys, in practice:

Grounded inputs — work starts from information that was supplied or verified, never assumed.
Transparency — the client sees what is missing, and why the process has not started.
Less rework — a gap is caught before the deliverable is built on it, instead of after.

This prevents assumptions from becoming requirements.

▫ To be exact about what backs that: all ten were verified by automated tests, not by ten paid runs. The live evidence on this page remains the router's twenty requests and the WF-001 pilot above.

A mention is not an answer (new in `v0.11.0`)

What this one proves: that the system checks whether a request actually answers the question, instead of matching the words it expects to find.

For example, a recruitment request needs to specify the seniority of the position. If it says "No senior role has been opened for this team," the word senior is present, but the position itself is not defined. The system asks for the missing information instead of starting work on a role that does not exist.

At the same time, it must not become overly restrictive. A request can contain the word "no" and still provide everything required — "No RFP was issued; the selection criteria are price and expertise." The criteria asked for are right there, so the request goes through. A system that keeps handing back requests that were fine is not a careful system, it is one people work around.

In short: it does not simply look for words, it checks whether the information answers the question. That is what makes the process more dependable without creating unnecessary friction for the people sending requests — and both sides of it are measured, not asserted.

▫ To be exact about what backs that: seventeen requests were written to mention the answer while stating it does not exist — fifteen are correctly refused, and the two that still get through are named one by one and re-checked at every test run. Fourteen others contain a "no" that does not concern the question, and all fourteen go through. Five questions are deliberately left out of the rule, because for them "no" really is the answer: asked whether personal data is involved, "no personal data is processed" is a complete answer.

Tested on real business briefs (new in `v0.11.0`)

What this one proves: that these rules were tested on real business briefs, not only on examples written for the test.

Anyone can set their own exam and pass it. The sample requests used to try these checks were written by the same hand as the checks — which proves very little.

So the checks were applied to briefs taken from actual live runs: documents written for real consulting and business needs, before these rules existed.

One example carries the whole point. Here is how one consulting brief described the client: "Mid-cap European industrial group (EU footprint, ~4,000 employees). Full AI consulting engagement: maturity audit, ROI business cases, a 12-24 month strategic AI roadmap, an ADKAR change-management plan…"

Normal business text, not a questionnaire. Before starting, the process checks whether the information it needs is actually there. Two of its ten questions:

Business information required	How the system reads the brief
Client name	The brief describes a "Mid-cap European industrial group" but gives no company name. The information is recorded as missing.
Engagement length	The only duration mentioned is a 12-24 month strategic roadmap. The system does not take this for the length of the engagement: it is the planning horizon, not how long the consultant is booked.

This matters because the brief was written before these rules existed. The system had to work on the original business context, not on a pattern written to suit the test.

The result: the checks work on real-world, free-form business requirements, and separate what is known from what is missing before work begins.

▫ To be exact about what backs that: the briefs came first, and these questions came months later. Put the old briefs back through them and forty-one of the seventy-eight questions are already answered, across seven processes. Three of those seven briefs are only a paragraph long, so they answer very little — which says more about their length than about the checks. Every unanswered question is listed and explained, one by one.

WF-001 — AI Product Scoping

What this one proves: that a raw brief becomes a backlog a team can start on, acceptance criteria attached — the stage where a project usually loses its first week.

Status: completed — failure: none
Result: 3 / 3 steps passed (catalog v4.0.0)

The scoping backbone, proven end to end. Three steps ran, each gated (STEP-02 was not part of this run).

Step	Agent	Verdict
`STEP-01`	`AGENT-BUSINESS-ANALYST`	pass
`STEP-03`	`AGENT-PO-SCRUM`	pass
`STEP-04`	`AGENT-QA-AGILE`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-001-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-BUSINESS-ANALYST", "catalogTag": "v4.0.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-PO-SCRUM",         "catalogTag": "v4.0.0", "verdict": "pass" },
    { "stepId": "STEP-04", "assetId": "AGENT-QA-AGILE",         "catalogTag": "v4.0.0", "verdict": "pass" }
  ]
}

WF-002 — SAFe Agile Delivery

What this one proves: that the artefacts a programme actually steers on — PI objectives, a ranked backlog, a committee dashboard — come out of one traced pass rather than three rounds of meetings.

Status: completed — failure: none
Result: 5 / 5 steps passed (catalog v3.27.0)

The SAFe delivery backbone: PI objectives, a prioritized program backlog, and an executive-committee dashboard, produced end to end.

Step	Agent	Verdict
`STEP-01`	`AGENT-PRODUCT-MANAGER-SAFE`	pass
`STEP-02`	`AGENT-RELEASE-TRAIN-ENGINEER`	pass
`STEP-03`	`AGENT-PO-SAFE`	pass
`STEP-04`	`AGENT-SCRUM-MASTER`	pass
`STEP-06`	`AGENT-CHEF-PROJET-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-002-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-PRODUCT-MANAGER-SAFE",   "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-RELEASE-TRAIN-ENGINEER", "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-PO-SAFE",                "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-04", "assetId": "AGENT-SCRUM-MASTER",           "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-06", "assetId": "AGENT-CHEF-PROJET-IA",         "catalogTag": "v3.27.0", "verdict": "pass" }
  ]
}

WF-003 — AI Application Launch (RAG customer-support chatbot, insurer)

What this one proves: that a build carries its cost case and its security review inside the run — the two reviews most often bolted on once the thing already exists.

Status: completed — failure: none
Result: 7 / 7 steps passed (catalog v3.27.0)

Seven steps, opening on a financial framing and closing on a security review, with the build in between.

Step	Agent	Verdict
`STEP-00`	`AGENT-FINANCIAL-ANALYST`	pass
`STEP-01`	`AGENT-PROMPT-ENGINEER`	pass
`STEP-02`	`AGENT-AI-ARCHITECT`	pass
`STEP-03`	`AGENT-DEV-PYTHON-IA`	pass
`STEP-04`	`AGENT-QA-AGILE`	pass
`STEP-05`	`AGENT-DEVOPS-CLOUD`	pass
`STEP-06`	`AGENT-SECURITE-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-003-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-00", "assetId": "AGENT-FINANCIAL-ANALYST", "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-01", "assetId": "AGENT-PROMPT-ENGINEER",   "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-AI-ARCHITECT",      "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-DEV-PYTHON-IA",     "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-04", "assetId": "AGENT-QA-AGILE",          "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-05", "assetId": "AGENT-DEVOPS-CLOUD",      "catalogTag": "v3.27.0", "verdict": "pass" },
    { "stepId": "STEP-06", "assetId": "AGENT-SECURITE-IA",       "catalogTag": "v3.27.0", "verdict": "pass" }
  ]
}

WF-004 — AI Consulting Engagement

What this one proves: that an engagement ends in something a client executive can read, and that the cost case is built along the way rather than argued afterwards.

Status: completed — failure: none
Result: 6 / 6 steps passed (catalog v4.1.0)

This run opens the fourth live-proven domain, Management & Consulting: a signed consulting engagement carried end to end, from maturity diagnostic to an executive-ready deliverable.

Step	Agent	Verdict
`STEP-01`	`AGENT-CONSULTANT-IA`	pass
`STEP-02`	`AGENT-FINANCIAL-ANALYST`	pass
`STEP-03`	`AGENT-CDO-DIRECTEUR-IA`	pass
`STEP-04`	`AGENT-CHANGE-MANAGER`	pass
`STEP-05`	`AGENT-FORMATEUR-IA`	pass
`STEP-07`	`AGENT-REDACTEUR-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-004-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-CONSULTANT-IA",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-FINANCIAL-ANALYST", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-CDO-DIRECTEUR-IA",  "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-04", "assetId": "AGENT-CHANGE-MANAGER",    "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-05", "assetId": "AGENT-FORMATEUR-IA",      "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-07", "assetId": "AGENT-REDACTEUR-IA",      "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

WF-005 — Strategic Intelligence & Growth

What this one proves: that a process is as long as its work requires and no longer — three steps here, seven for the chatbot build above.

Status: completed — failure: none
Result: 3 / 3 steps passed (catalog v4.1.0)

The runtime's lightest backbone: raw market signals become a qualified intelligence radar, an SEO content plan, and publishable posts. Three agents, every blocking and advisory check passing, and one field carried from each step into the next (highlights → topics) — the handoff idiom, meaning the step that follows reads the named output of the step before it rather than starting from the original brief again.

Step	Agent	Verdict
`STEP-01`	`AGENT-VEILLE-STRATEGIQUE`	pass
`STEP-02`	`AGENT-GROWTH-IA`	pass
`STEP-03`	`AGENT-REDACTEUR-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-005-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-VEILLE-STRATEGIQUE", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-GROWTH-IA",          "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-REDACTEUR-IA",       "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

WF-006 — Pre-sales / Commercial Proposal

What this one proves: that a gate which can stop a run also lets a legitimate one through. A gate that only ever says no is not a control, it is an obstacle.

Status: completed — failure: none
Result: 6 / 6 steps passed (catalog v4.1.0)

The complement to WF-008: where WF-008's counter-review gate (a second, independent reviewer whose approval is required before the deliverable may go out) said no, WF-006's opening GO / NO-GO qualification gate said yes on a legitimate opportunity, and the pre-sales chain ran through to the proposal. These are two different gates in two different processes — what they share is that each one had the authority to halt its run and had to be satisfied.

A step id can carry a letter — STEP-03A here, STEP-02A and STEP-06C further down. The letter is how a stage gets added or split without renumbering the ones already there: STEP-03A and STEP-03B are two branches running side by side, while STEP-06C in WF-008 is a stage that runs only when the case calls for it. Ids stay stable from one run to the next, which is what lets two traces of the same process be read against each other.

Step	Agent	Verdict
`STEP-01`	`AGENT-CONSULTANT-IA`	pass
`STEP-02`	`AGENT-BUSINESS-ANALYST`	pass
`STEP-03A`	`AGENT-AI-ARCHITECT`	pass
`STEP-04`	`AGENT-CHEF-PROJET-IA`	pass
`STEP-05`	`AGENT-FINANCIAL-ANALYST`	pass
`STEP-07`	`AGENT-REDACTEUR-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-006-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01",  "assetId": "AGENT-CONSULTANT-IA",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02",  "assetId": "AGENT-BUSINESS-ANALYST",  "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03A", "assetId": "AGENT-AI-ARCHITECT",      "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-04",  "assetId": "AGENT-CHEF-PROJET-IA",    "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-05",  "assetId": "AGENT-FINANCIAL-ANALYST", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-07",  "assetId": "AGENT-REDACTEUR-IA",      "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

WF-007 — Mission Onboarding — Day 1–5

What this one proves: that the first days of an engagement are a deliverable in their own right, not the time everyone spends finding out who decides what.

Status: completed — failure: none
Result: 4 / 4 steps passed (catalog v4.1.0)

The first days of a new engagement, carried end to end: a kickoff plan with a provisional RACI, a client-context sheet, a stakeholder engagement plan, and a Day-1 report. Handoff idiom raci → clientContext → engagementPlan; the writer synthesizes the onboarding kit from all prior deliverables.

Step	Agent	Verdict
`STEP-01`	`AGENT-CHEF-PROJET-IA`	pass
`STEP-02`	`AGENT-BUSINESS-ANALYST`	pass
`STEP-03`	`AGENT-CHANGE-MANAGER`	pass
`STEP-05`	`AGENT-REDACTEUR-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-007-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-CHEF-PROJET-IA",  "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-BUSINESS-ANALYST", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-CHANGE-MANAGER",   "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-05", "assetId": "AGENT-REDACTEUR-IA",     "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

What this one proves: that the system withholds a deliverable it is not entitled to issue — and records that outcome as plainly as it records a success. This is the run that did not finish, kept here on the same footing as the nine that did.

Status: ⟲ returned for rework — failure: STEP-06C (counter-review gate)
Result: the six pre-report steps passed; the counter-review gate then returned the audit, so the report step (STEP-07) was withheld by design (catalog v4.1.0)

This is a fail-closed halt, on purpose. The process carries a counter-review clearance gate at STEP-06C: the AI Methodology Auditor answers with one of two words — cleared (the method holds, the report can go out) or returned (it does not) — and only cleared lets the run reach the report. Here it answered returned: five documented reservations, a four-entry bias log, and ISTQB exit criteria. The blocking criterion audit-verdict-cleared was therefore not satisfied and the run stopped before the deliverable; the status shown for WF-008 in the table at the top of this page takes its name from that verdict. The first live run where a gate blocks a report rather than passing it.

Step	Agent	Verdict
`STEP-01`	`AGENT-JURIDIQUE-IA`	pass
`STEP-02`	`AGENT-AI-ARCHITECT`	pass
`STEP-03`	`AGENT-SECURITE-IA`	pass
`STEP-04`	`AGENT-DATA-ENGINEER`	pass
`STEP-05`	`AGENT-CDO-DIRECTEUR-IA`	pass
`STEP-06`	`AGENT-CHANGE-MANAGER`	pass
`STEP-06C`	`AGENT-AUDIT-METHODO-IA`	fail — audit returned
`STEP-07`	— (report)	withheld

STEP-06C's fail is the gate refusing to clear, not a broken step: the auditor's own verdict was returned (not cleared), and the blocking criterion audit-verdict-cleared requires cleared. The run then halted fail-closed, so STEP-07 never ran and no report was emitted.

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-008-live-result.json:

{
  "status": "failed",
  "failure": {
    "stepId": "STEP-06C",
    "kind": "eval-gate",
    "message": "Eval gate \"STEP-06C\" failed (1 blocking criterion(s): audit-verdict-cleared)"
  },
  "traces": [
    { "stepId": "STEP-01",  "assetId": "AGENT-JURIDIQUE-IA",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02",  "assetId": "AGENT-AI-ARCHITECT",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03",  "assetId": "AGENT-SECURITE-IA",      "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-04",  "assetId": "AGENT-DATA-ENGINEER",    "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-05",  "assetId": "AGENT-CDO-DIRECTEUR-IA", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-06",  "assetId": "AGENT-CHANGE-MANAGER",   "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-06C", "assetId": "AGENT-AUDIT-METHODO-IA", "catalogTag": "v4.1.0", "verdict": "fail" }
  ]
}

The top-level status is failed because the run is fail-closed: a gate that returns a deliverable stops the spine — one workflow's ordered chain of steps, from the first to the last. Read it as returned for rework, not as a broken pipeline — every step that ran, ran clean, and the halt is the design working.

WF-009 — IT / AI Recruitment

What this one proves: that a scoring gate refuses an empty shortlist instead of ranking whatever it is handed. This is the one workflow shown twice — once passing, once refusing — because a gate that has never said no has not been tested.

Status: completed — failure: none
Result: 6 / 6 steps passed (catalog v4.1.0)

The fifth live-provable domain, HR & Talent: a hiring need becomes a need sheet, a technical assessment grid, a scored shortlist, and a publishable job ad. The last three backbone steps are carried by AGENT-RH-IA (sourcing/scoring, selection, offer).

Synthetic candidate pool — by design, not autonomous sourcing

CVs are exogenous to the workflow (they arrive after the ad is published), so the run is proven on a synthetic, fictional candidate pool provided into the run. This is a demonstrator affordance, GDPR-safe for a public trace — a real deployment would inject candidates at the sourcing step via an ATS side-channel, never thread real personal data through upstream steps. The content was inspected, not just the verdicts: the seeded weak profile scored 20 / 100 and was excluded, and the candidate it selected is not the one the test expected — it reasoned, it did not echo.

Step	Agent	Verdict
`STEP-01`	`AGENT-BUSINESS-ANALYST`	pass
`STEP-02A`	`AGENT-CONSULTANT-IA`	pass
`STEP-03`	`AGENT-REDACTEUR-IA`	pass
`STEP-04`	`AGENT-RH-IA`	pass
`STEP-05`	`AGENT-RH-IA`	pass
`STEP-06`	`AGENT-RH-IA`	pass

The gate, saying yes — the first of two traces

Verbatim excerpt from docs/audit/live-runs/wf-009-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01",  "assetId": "AGENT-BUSINESS-ANALYST", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02A", "assetId": "AGENT-CONSULTANT-IA",    "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03",  "assetId": "AGENT-REDACTEUR-IA",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-04",  "assetId": "AGENT-RH-IA",            "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-05",  "assetId": "AGENT-RH-IA",            "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-06",  "assetId": "AGENT-RH-IA",            "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

The same gate, saying no — a second WF-009 trace

To prove the shortlist gate discriminates rather than rubber-stamps, the same spine was run with a no-candidate seed. STEP-04's blocking criterion rh-shortlist-validated counts real candidates; with none, it fails closed and the run halts before selection — the honest opposite of the completed run. Fail-closed is the choice that decides everything else on this page: when a check is not satisfied, the default is to stop, not to carry on and hope. It is the more expensive default, and it is the reason a run that finishes here means something.

Step	Agent	Verdict
`STEP-01`	`AGENT-BUSINESS-ANALYST`	pass
`STEP-02A`	`AGENT-CONSULTANT-IA`	pass
`STEP-03`	`AGENT-REDACTEUR-IA`	pass
`STEP-04`	`AGENT-RH-IA`	fail — shortlist not validated

Two words in the excerpt below carry that halt. The run's status is failed — it did not reach its end — and the kind of failure is eval-gate, meaning a quality check declined to let the run continue, rather than something breaking. A blocking criterion is a check a run cannot proceed without; rh-shortlist-validated is the name of the one that stopped this one.

Verbatim excerpt from docs/audit/live-runs/wf-009-live-result-gate-halt.json:

{
  "status": "failed",
  "failure": {
    "stepId": "STEP-04",
    "kind": "eval-gate",
    "message": "Eval gate \"STEP-04\" failed (1 blocking criterion(s): rh-shortlist-validated)"
  },
  "traces": [
    { "stepId": "STEP-01",  "assetId": "AGENT-BUSINESS-ANALYST", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02A", "assetId": "AGENT-CONSULTANT-IA",    "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03",  "assetId": "AGENT-REDACTEUR-IA",     "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-04",  "assetId": "AGENT-RH-IA",            "catalogTag": "v4.1.0", "verdict": "fail" }
  ]
}

The two traces together are the point: one gate, a pass on real substance and a fail-closed halt on an empty pool.

WF-010 — Project Post-mortem

What this one proves: that a finished project is turned into something the next one can use — root cause, quality debt and team review in a single pass, while anyone still remembers.

Status: completed — failure: none
Result: 4 / 4 steps passed (catalog v4.1.0)

The last of the ten to be run live: a closed project becomes a 5-Whys root-cause analysis, a quality and technical-debt review, a team review, and a lessons-learned report. Handoff idiom improvementPlan → qualityReview → teamReview; the writer synthesizes the report from all prior deliverables.

Step	Agent	Verdict
`STEP-01`	`AGENT-CHEF-PROJET-IA`	pass
`STEP-02`	`AGENT-QA-AGILE`	pass
`STEP-03`	`AGENT-CHANGE-MANAGER`	pass
`STEP-06`	`AGENT-REDACTEUR-IA`	pass

Evidence (excerpt from the live-run JSON)

Verbatim excerpt from docs/audit/live-runs/wf-010-live-result.json:

{
  "status": "completed",
  "failure": null,
  "traces": [
    { "stepId": "STEP-01", "assetId": "AGENT-CHEF-PROJET-IA", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-02", "assetId": "AGENT-QA-AGILE",       "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-03", "assetId": "AGENT-CHANGE-MANAGER", "catalogTag": "v4.1.0", "verdict": "pass" },
    { "stepId": "STEP-06", "assetId": "AGENT-REDACTEUR-IA",   "catalogTag": "v4.1.0", "verdict": "pass" }
  ]
}

Live-run evidence in the repository →

What these proofs demonstrate

The system does not treat a fluent output as proof of correctness. It checks whether the request is ready, whether the process it picked is the right one, whether each step meets its criteria, and whether the run can be reconstructed afterwards.

If the information is missing, it asks. If a check fails, it stops. If something cannot be verified, it records that fact. It does not pretend to know.

This is where "refuse to guess" stops being a promise and becomes something a reader can check: NO_MATCH, PARAMS_MISSING, a workflow that halts at 6 / 7, the catalogue version behind every run, and the traces that let anyone re-open it — one line at a time.

Live proofs

Proven runs

WF-000 — Dispatch (router + pilot)

Parameter checks — from one workflow to all ten (new in v0.10.0)

A mention is not an answer (new in v0.11.0)

Tested on real business briefs (new in v0.11.0)

WF-001 — AI Product Scoping

Evidence (excerpt from the live-run JSON)

WF-002 — SAFe Agile Delivery

Evidence (excerpt from the live-run JSON)

WF-003 — AI Application Launch (RAG customer-support chatbot, insurer)

Evidence (excerpt from the live-run JSON)

WF-004 — AI Consulting Engagement

Evidence (excerpt from the live-run JSON)

WF-005 — Strategic Intelligence & Growth

Evidence (excerpt from the live-run JSON)

WF-006 — Pre-sales / Commercial Proposal

Evidence (excerpt from the live-run JSON)

WF-007 — Mission Onboarding — Day 1–5

Evidence (excerpt from the live-run JSON)

WF-008 — AI Act / GDPR Compliance Audit

Evidence (excerpt from the live-run JSON)

WF-009 — IT / AI Recruitment

The gate, saying yes — the first of two traces

The same gate, saying no — a second WF-009 trace

WF-010 — Project Post-mortem

Evidence (excerpt from the live-run JSON)

What these proofs demonstrate

Parameter checks — from one workflow to all ten (new in `v0.10.0`)

A mention is not an answer (new in `v0.11.0`)

Tested on real business briefs (new in `v0.11.0`)