The quantitative scorecard

Time-to-Solution Dashboard

The Agentic-Readiness Scorecard is an opinion. This is the instrument that turns it into a number. Every agent and tool emits a small event as it works; a stdlib aggregator rolls them into the handful of metrics that name the real blocker — so "get better quickly" stops being a feeling. Below is the pipeline measured against one bar: a complete design — validated in simulation, backed by full program management — in a day.

v0.1 · runs on a laptop, no server Reconstructed from the QX-250 build Spec + aggregator below

The baseline to beat

This build, measured

These measure the engineering solution only — reliability, simulation, RFLP, electrical, FPGA, software, mechanical, program, BOM, verification, standards, proposal. Building this site to document it is meta-work and is excluded from the numbers.

Time-to-solution23.8 h

agent-active build of the engineering solution across 13 deliverables — not a day yet, but every tool action was autonomous

Human touches16

direction, not operation — no human ever ran a tool

Prompts / deliverable0.7

under one prompt per deliverable — the engineering itself was largely self-directed

Verification coverage57%

up from 40% — flight-verification and native V&V are now machine-checked

Rework escapes7

~0.5 per deliverable — the thread kept catching real conflicts (mass, as-built, v2→v3)

Iterations34

concentrated where it was cheap: headless. GUIs got 2–4.

The story in one line. The agent did ~24 hours of real building across 13 engineering deliverables — with a human giving only 9 prompts (and 4 gate approvals), while 57% of "done" was verified by machine and 7 of 13 deliverables hit a rework escape. Not a day, and not yet trustworthy at speed — but every tool action was autonomous, and the engineering itself needed little steering. That is the honest baseline, and every one of those numbers is a lever.

Where the day goes

Time by domain

Agent-active hours per domain (includes seam time). The engineering is spread — no single domain dominates — which is exactly why the connective tissue, not any one tool, decides the total.

FPGA
3.5 h
Electrical
3.3 h
Docs / site
3.0 h
RFLP
2.8 h
Performance
2.0 h
Program (WBS)
1.8 h
Manufacturing
1.7 h
Reliability
1.5 h
Software
1.5 h
Verification
1.2 h
Standards
1.0 h

The autonomy signal

Human touches — by kind

This is the metric that matters most. Touch time was small (~62 min); touch count is the truth: the agent needed a human to direct the engineering 12 times. Only approve should survive an agentic program layer — every prompt and unblock is work the WBS orchestrator has to absorb.

None of these were tool operations. Every touch here is a human giving direction — not a human running a tool. Across the entire build, zero tool actions in NX, Capital, Teamcenter, Simcenter Amesim or MADe were performed by a human; the agent operated all of them itself. This chart is the directional-autonomy gap, not a hands-on-tool gap — tool operation was already 100% autonomous.
Prompt (direction)
22
Unblock (fix)
2
Approve (gate) ✓
2
Target state: the green approve touches stay (a human owns the gates); the 12 orange touches go to zero as the agentic program layer drives the work from a structured plan instead of a human prompting each step. Touches-per-deliverable is the single number to watch fall.

Design is a loop

Iterations by domain

Where the tool was headless and fast, the agent iterated freely (Performance: 9 loops — demo → purpose-built → native submodel → re-flown at as-built mass). Where it was a GUI, it got 2–4. Iteration count tracks exactly with which tools can sit inside the loop.

Performance ⚡
8
Docs / site
6
Electrical
4
RFLP
3
Program (WBS)
3
Reliability · FPGA · SW · Mfg
2
Verification · Standards
1

The trust tax

Rework / defect-escape log

Every escape is a place automated cross-domain verification was missing. These are the actual seven from this build — the honest cost of building fast without machine-checked criteria.

DeliverableCauseWhat had to change
amesim-6dofHeadless generator omits the M6DOF/EMD link archivesHand-fix the linker before it would compile
logical-architectureAs-analysed (dual battery) ≠ as-designed (single-string)Add BT2 / U2 / PWR1 to the architecture
compute.htmlFalse claim: "the FPGA is device U2 in Capital" (U2 is the redundant FC)Corrected — after a cross-session catch, not an automated one
nav.jsTwo agent sessions clobbered the same fileHand-coordinated merge (the concurrency gap, live)
nav.jscleanUrls broke the active-state (/compute vs compute.html)Normalize the href — a silent bug found only by eye
rflp.htmlProse said 9 functions / 10 blocks; Teamcenter had 13 / 13Reconcile the counts

Escape rate: ~0.5 per deliverable. Most of them would have been caught by an automated conformance / verification check — the P1 fix on the scorecard.

The hidden tax & the bill

Seams and cost

Seam-crossing cost

HandoffTimeFailures
bundle → Teamcenter (SOA)15 min2 (naming-rule reject → auto-id)
bundle → Capital (import)20 min5 (test imports to nail the UID grammar)

Seam tax: 2.5% of TTS, 7 retries. Low here only because we'd already built the neutral bundle + bridge; without it, the seams are where most of the day is lost.

The bill

Tokens57 M

agent output across the engineering build

License-hours13

tool seat-time — the economic question: cheaper than a team-week?

How it works

One event stream → one aggregator → this page

The whole instrument is four files and no infrastructure. An agent (or tool wrapper) calls a ~10-line emitter — one shell line per action; a stdlib script rolls the stream into the metrics above; a static page renders them. It runs the moment a single wrapper starts emitting — start with the headless runners (cheap, high-signal) and a one-line-per-turn human-touch counter and the picture is already actionable.

events.jsonl · the append-only contract View the log ↗
// one line per meaningful action — tool-agnostic, human-readable
{"event":"work_completed","domain":"performance","tool":"Amesim",
 "deliverable":"qx250-6dof","duration_s":7200,"result":"pass",
 "meta":{"iterations":8}}
{"event":"human_touch","meta":{"kind":"prompt"},"duration_s":120}
{"event":"rework","deliverable":"compute.html",
 "meta":{"cause":"false claim: FPGA is a device in Capital"}}
{"event":"verification","deliverable":"safety-interlock","result":"pass",
 "meta":{"method":"formal","machine_checkable":true}}
emit.py · the ~10-line emitter agents call View emit.py ↗
# agents don't hand-write JSON — one shell line per action:
python emit.py human_touch --kind prompt          # once per turn — the autonomy number
python emit.py work_completed --domain fpga --deliverable gateware --duration_s 900 --iterations 2
python emit.py rework --deliverable compute.html --cause "false claim: FPGA in Capital"
python emit.py verification --deliverable safety --method formal --machine_checkable true

python aggregate.py events.jsonl metrics.json     # roll the log into this dashboard

We proved the loop by logging this very task — building the emitter — with the emitter: it captured the prompt, the work, and (honestly) a real rework event for a CLI bug we'd just fixed, then aggregated to live metrics. The single habit that matters: emit human_touch --kind prompt once per turn — that line, summed over a build, is the autonomy number the program layer exists to drive to zero.

This page is data-driven. Every number, bar and row above is rendered at load from metrics.json — recompute it with aggregate.py and redeploy, and the dashboard updates itself, no HTML edits. The current numbers are a reconstruction of the QX-250 engineering build — the site work that documents it (the docs domain) is excluded by the aggregator, so this measures the solution, not the website. It already shows one axis moving the right way: verification coverage rose 40% → 57% as the flight re-verification and native V&V landed. The goal is to capture the next build for real and keep comparing: did time-to-solution fall, did prompts-per-deliverable drop, did coverage keep rising? That comparison is the whole game.

Read the full design and the runnable code: Spec (v0.1) ↗ · README (copy-paste) ↗ · emit.py ↗ · aggregate.py ↗ · events.sample.jsonl ↗ · metrics.json ↗