Skip to main content

Built by Eclipse - ARC

Your discovery workshops, carried all the way to build.

ARC takes the transcripts and recordings of a ServiceNow discovery workshop and produces the entire delivery chain behind them: as-is analysis, process design, requirements, solution design, a decomposed backlog, and the configuration and test work that follows.

Trace chain, unbroken

One input. Twenty-five-plus deliverables.

Every one of them carrying a citation back to something a stakeholder actually said, in a session you can name, on a line you can find.

Trace chain unbroken
  1. Workshop transcript
  2. Visual evidence captured and timestamped VE-014
  3. Gap raised, cited to session and line G-07
  4. Requirement written and priority-tagged R-042
  5. Design decision taken, alternatives recorded DD-09
  6. Feature traced to its requirement FEAT-11
  7. User story with acceptance criteria STRY-58
  8. Backlog imported to the platform

Ask why a story exists and the answer is a citation, not a recollection. Governance asks that question eventually. ARC answers it on the first request.

Replay

Watch the harness run.

ARC is an agentic harness, not a prompt. A deterministic replay of one module's pipeline, on the same clock every time, showing which sub-agents are deployed at each beat, what each one is allowed to see, and what it hands back before the next tier is permitted to start.

ARC agentic harness idle · run/pm-05 · 0 running · 0 spawned
Standing by 00:00

Event stream0 events

Sub-agents deployedcontext-isolated

Tiers0 / 15

Run output

Trace chain

Press play to run the pipeline end to end.

The six faithfulness-verification agents are ARC's real ones, named as they are defined in the pipeline with their real context boundaries; the other roster entries name the role the agents at that tier perform. Register codes and transcript lines in the replay are illustrative; the figures it counts up to are the real ones: 15 tiers, 135 quality checks, and the 94.7% and 93.2% gate scores recorded on the Security Operations engagement.

The chain

What happens between the last workshop and the first sprint.

Six stages, run in order, each gated. Nothing advances until the stage behind it passes. The tier codes are the pipeline's own: they appear in every document ARC produces, which is how you find the working out.

T0

Workshop capture

Recordings scanned for on-screen evidence: instance screenshots, whiteboards, shared documents. Every artefact timestamped and registered before analysis starts.

T1-T4

As-is analysis

Per-workshop analysis, verified against the transcript by isolated agents, then consolidated into one enterprise architecture baseline, a gap register, a branded slide deck and a written companion guide.

T5-T7

Maturity and target state

Where the organisation sits today, scored; where the platform should take it; and which part of that is inside the statement of work versus outside it. Scope arguments happen here, on paper, not in month four.

T8-T10

Process design, requirements, solution design

ServiceNow process design documented section by section, requirements numbered and priority-tagged, and a solution design that records each decision with the reason it was taken and what was rejected.

T11-T12

Backlog and governance

Epics, features and user stories with acceptance criteria, prioritised and ready to import into the platform's work-item workspace, plus the register that proves every pain point raised in a workshop is covered by something in the backlog.

Build

Configuration, AI agent setup and test

The same evidence chain carries into delivery: ServiceNow configuration and scoped-app development, Now Assist AI agent and agentic workflow setup, and test design written from the acceptance criteria the stories already carry.

The team in the box

Five roles' worth of production work, done once and done the same way every time.

ARC does not replace the people. It replaces the document-production half of their week, the half nobody joined the profession to do, and hands the judgement work back to them with the drafting already finished.

Role What ARC produces What stays human
Business analyst Process discovery documents and a numbered business requirements document, each requirement traced to the workshop moment that produced it. Reading the room. Knowing which stakeholder is answering a different question from the one they were asked.
Solution architect Solution design document with numbered design decisions, component architecture, and the rejected options recorded alongside the chosen one. The genuinely hard platform calls, and the ones that turn on politics rather than architecture.
Project and product manager Epic, feature and story hierarchy with prioritisation, coverage matrix and a governance register that survives an audit. Sequencing against real delivery constraints. Managing the people and the money.
ServiceNow developer Stories that arrive with acceptance criteria, design decisions and a citation trail attached, plus configuration and scoped-app build against them. The build judgement that only comes from having broken something similar before.
Tester Test design derived from the acceptance criteria the stories already carry, mapped back to the requirement each one proves. Exploratory testing, and the instinct for where a platform quietly lies to you.

Why you can trust the output

ARC's main job is trying to prove its own work wrong.

Two verification gates sit inside the pipeline, and neither is advisory. Each uses sub-agents with genuine information barriers: the agent extracting claims never sees the transcript; the agent searching for evidence never sees the document it is checking. Confirmation bias is prevented structurally, not asked for politely.

T1b

Faithfulness verification

Six isolated agents check every workshop analysis against the transcript it came from: claims extracted, evidence searched, content independently re-extracted, cross-session contamination checked, corrections applied.

Hard gate: 85%+ faithfulness, zero contradictions

T10b

Adversarial verification

The requirements and design are stress-tested against six named failure modes before a stakeholder sees them:

  • Fabrication: a source that was never spoken
  • Misattribution: the right fact, the wrong owner
  • Inference leakage: a guess wearing evidence's clothes
  • Severity inflation: a nuisance promoted to a risk
  • Phantom consensus: agreement nobody actually gave
  • Omission: the finding that quietly went missing

Most systems optimise for the impressive first impression. This one optimises for surviving the second reading.

The evidence

The method came out of a failure, and the numbers come from the recovery.

ARC was built from a correction register: a UK government asset-management engagement where the documents looked professional and human review found 525 sub-findings across 40 files. Every failure was catalogued, and the pipeline was designed to make each one structurally impossible. The measure that matters is what human reviewers have found since.

Before ARC existed
65.6 findings per workshop session
Problem Management
3.6 findings per session
Change Management
2.1 findings per session
Security Operations
0.0 findings: one minor correction

Recorded, not polished. The Change Management run passed its faithfulness gate conditionally at 77%, with high omission on several workshops and cross-session contamination flagged at 23%. It is in the register because that is what the register is for. A system that only reports its good runs is not a verification system.

Getting started

Give it one module's workshops. Judge it on what comes back.

ARC is parameterised per module and has run across Software Asset Management, Problem Management, Change Management, Security Operations, Major Incident Management and Request Management.

  1. You bring the workshop recordings and transcripts, the statement of work, and whichever reference process you are designing against.

  2. ARC runs the as-is baseline first, so you can check its reading of your organisation before anything downstream is built on it.

  3. You review at the gates. Every gate is a document, not a status call.

  4. What you keep at the end is the full reasoning chain, not a deck that only made sense to the consultant who wrote it.

Pipeline figures, gate thresholds and finding rates are drawn from ARC's own execution record across six engagements. The build lane (ServiceNow configuration, AI agent setup and test design) runs on the same evidence chain and toolchain but sits outside the T0-T12 tiers, so the verification metrics above cover the advisory suites only.

See it run on your own transcripts.

Give ARC one module's workshops and judge it on what comes back.