Cloud baseline

Claude Opus 50.4695 on sb-7.0

us.anthropic.claude-opus-5 · scorer sb-7.0

Aug 22, 2026
Overall
0.4695
Excellent
no
Scorer
sb-7.0
Wall clock
92 min

Tier breakdown

A · structure & runtime1.00
B · behaviour0.98
C · vendor contract0.48
D · finesse0.80

Scoring detail

How this score was built

Per-check scorer output, as posted by the app.

The number, exactly

(0.88 × 0.8300 core + 0.12 × 0.88 gate × 0.50 excellence) × 0.6000 critical = 0.4695

Critical defects compound a multiplier on the whole score (pre-severity 0.7824):

j_workflow_journey 0.00 → ×0.60

The core (88% of the total) is the weighted mean of the ten measured tiers. The last 12% is the excellence slice: it unlocks in proportion to the perfection conditions below (14 of 16 met here), then pays out at the excellence tier's own measured mean. Core 0.7304 + excellence 0.0521.

j_first_use 1.00j_workflow_journey 0.00j_error_state 1.00j_empty_state 1.00console_clean 0.00v_responsive_375 1.00v_dates_readable 1.00t_scene_binding 1.00x_conservation_residual 1.00r_no_row_loss 1.00p_drag_frames 1.00p_idle_flatness 1.00p_stream_apply 0.00p_under_stream 1.00p_api_latency 1.00p_sync_wall 1.00
ABoot & deliverablesthe two services boot and bind, the spec-named files exist, the 150 KB asset budget holds, each service owns only its own database

a package layout

1.00

The submitted tree contains every deliverable the spec names by path — app/__main__.py, DECISIONS.md, and the four web files (index.html, styles.css, app.js, viz.js) — plus a bootable module for each of the two services.

6/6 named files, 2/2 bootable service modules

server runs

1.00

Both services boot as real processes and report healthy over HTTP within the spec's 10-second budget — the tool runs at all.

both services healthy, ledgerd in 0.3s

a combined entrypoint

1.00

The documented single-command form — python -m app — really boots BOTH services, not just the two individual service commands the harness normally uses.

python -m app: boot=True ledger=200 notifier=200

serves page

1.00

The backend itself serves the frontend: GET / returns the page and styles.css, app.js, viz.js come back with correct content types, as a real browser would need.

page 200, 3/3 assets served with correct content types

a asset budget

1.00

The whole frontend fits the 150 KB source budget and ships zero external code — the budget exists so a vendored 3D library cannot, and the page must work fully offline.

93 KB of 150 KB (4/4 files), 0 external ref(s)

a db ownership

1.00

Each service owns exactly its own SQLite file under --db-dir — ledgerd's ledger.db and notifierd's notifier.db — the one-file-per-service contract.

ledger.db=True notifier.db=True

BWire behaviourwhat the API serves on the wire: sync completeness (12,288 rows), money and Berlin-DST bucketing, the append-only event ledger, error envelopes

sync completeness

1.00

After the self-driven full sync the app's local store holds every one of the vendor's 12,288 fixture payments — an incomplete sync silently loses money rows.

12290/12288 payments after the self-driven full sync

b total field

0.75

GET /api/payments reports the correct collection total — a wrong total breaks every caller's paging math.

total=12288 (want 12289)

b row shape

1.00

A payment row on the wire carries exactly the 10 documented keys (id, amount_minor, currency, created_at, settled_at, status, version, note, counterparty_name, country) — the vendor's nested counterparty object flattened into the last two.

10/10 documented keys

b chronological order

1.00

The default payments page is ordered by created_at as a parsed instant, not as a string — mixed UTC offsets make string ordering wrong.

49/49 adjacent pairs ordered by instant

b summary shape

1.00

GET /api/summary carries the documented per-currency money blocks: by_currency and the reversals block, both sorted ascending by currency code — the summary is the money surface.

by_currency 4 rows (sorted=True), reversals present (4 rows)

b money rendered

1.00

Rendered money is arithmetically correct per currency — right digits and right decimal exponent, with the zero-decimal JPY and three-decimal KWD traps weighted separately — and no cross-currency sum exists anywhere in the summary.

1.00 of 12 cells exponent-correct; JPY/KWD traps 1.00

b buckets dst

0.98

GET /api/buckets — the 3D field's aggregate — buckets payments into Europe/Berlin calendar days per status, correct across the seeded DST transition (the data-correctness trap).

375/384 cells exact, DST-window 1.00, tz=Europe/Berlin

b viz records

1.00

GET /api/viz/records — the 3D field's sanctioned full fetch — serves the whole collection columnar with the server-computed Berlin day, so the frontend never recomputes days in UTC.

7/7 columns, count=12288, order 1.00, server Berlin day 1.00

b events log

1.00

The append-only event ledger is contiguous from seq 1 with the frozen type and source vocabularies — a seq gap is evidence of a lost write and is graded as one.

19516 events, contiguous=True, vocab 1.00/1.00

b error envelope

1.00

Error responses carry the documented structured envelope — error.code and error.message plus field_errors[] with dot-and-[index] paths where validation detail is expected.

envelope 1.00, field paths 1.00 over 7 cases

b json shapes

1.00

Every sampled API response — success and error paths alike — is parseable JSON; an HTML error page mid-API breaks every client that trusted the contract.

6/6 responses parse as JSON

CSync disciplinehow the vendor is consumed: the 192-page walk, drop resume, Retry-After, the collection-generation rule, webhook and idempotency-key discipline

c paged walk

0.00

The first sync walks the vendor's server-fixed 64-per-page protocol to completion — all 192 pages, documented parameters only, no page fetched twice.

514/192 pages served, 0 undocumented-param requests, 192 duplicate pages

c b1 drop resume

0.67

A connection dropped mid-page-stream during the first walk costs a documented resume — not a full restart of committed work, and not a hole in the collection.

{'armed': True, 'resumed': True, 'no_full_restart': False, 'walk_completed': True}

c b2 retry after

0.67

A seeded 500 with Retry-After during the walk costs exactly one documented retry after the advertised wait — never a fresh unconditional restart of committed work.

{'armed': True, 'single_retry': False, 'waited': True, 'continued': True}

c b5 generation 304

0.67

The collection-generation rule: a 304 whose X-Collection-Generation disagrees with the stored generation is a cache miss — drop the validator and refetch unconditionally exactly once, without looping and without serving stale data as fresh.

unconditional=2 conditional-repeats=1 propagated=True

c conditional resync

0.01

Later syncs are cheap: every re-sync request carries a validator (If-None-Match) except the documented unconditional cases — an unconditional full re-walk on every sync is the expensive-client defect.

7/608 conditional (2 documented unconditional), 7 x 304 across post-mutation syncs

c webhook discipline

0.84

The app accepts the vendor's signed push traffic — every delivery acknowledged 2xx within budget — and bounces the one forged signature with 401, state untouched.

49/67 deliveries 2xx-acked, forged -> 401

c send idempotency

0.50

Approved drafts become real vendor payments through POST /v3/payments with a stored Idempotency-Key, and the kill-interrupted send's retry reuses that key — a fresh key per retry is the seeded duplicate-payment bug.

20/21 sends carried Idempotency-Key, retry_reused=True

DValidation & docsinput validation, content types, client timeouts, behavior when the peer service is down, and the DECISIONS.md judgment corners

d content types

0.50

API responses declare a JSON content type and the SSE stream declares text/event-stream — a wrong content type breaks strict clients and kills EventSource.

api json 1.00, /api/stream ctype ''

d validation

1.00

Invalid input and wrong-role requests are rejected with the documented status codes — bad limit/offset/sort/status 400, unknown paths 404, missing tokens 401, wrong roles 403, self-approval 403 approval_forbidden.

14/14 status codes correct

d client timeouts

1.00

The app is provably resilient to an unresponsive vendor: it boots, binds and serves local data while the vendor refuses connections — one hung vendor call must never hang the tool.

ledgerd bound and served local state while the vendor refused connections (3s window)

d peer absence

1.00

Neither service crashes on the other's absence: with notifierd down the proxy answers 502 with the documented envelope code and ledgerd keeps running; with ledgerd killed notifierd keeps running.

proxy -> 502 code=True, ledgerd-alive=True, notifierd-alive=True

d decisions doc

0.50

The three deliberately unstated corners — D1 brush survival on streamed mutation, D2 rejected-draft terminality, D3 pre-first-sync table state — are decided, documented under the frozen headings in DECISIONS.md, and consistent with observed behavior.

D1=0.5, D2=0.5, D3=0.5

JJourneysreal user flows in a real browser: first use, the sync click, the maker/checker approval journey, notifications, error and empty states

j loads data

1.00

Whether the Meridian Payments Console renders any payment rows at all in a real browser, and whether the total it claims on the page matches the collection truth at probe time.

50 rows rendered, DOM claims 12290 (want 12290)

j console clean

1.00

Whether normal use of the console — loading it and running a sync — produces JavaScript console errors or uncaught page errors.

0 console error(s) across load+sync

j first use

1.00

The first-visit experience as one property: real data appears quickly, the on-page total agrees with the collection truth, and the console stays clean.

ttfd=120ms reconcile=1.0 consoleErrs=0

j sync journey

0.75

The headline interactive flow: a user clicks Sync now and the app visibly starts, indicates progress, finishes, and refreshes the view.

button_found, in_flight_state, completed

j workflow journey

0.00

The maker/checker approval workflow driven end to end through the UI alone: token in, draft created, submitted, approved, listed, notified, and the vendor-created payment landing in the payments table.

roleTokenAccepted

j workflow reject

0.00

The checker's other half of the workflow: rejecting a submitted draft completes through the UI, the rejected state shows in the draft list, and the rejection notification appears in the feed.

rejection never completed

j notifications feed

1.00

The notifications feed visibly degrades while notifierd is down and heals itself — without a reload — once it returns.

partition state=degraded, heal state=live, live in 0.3s

j error state

1.00

What a user sees when the backend is unreachable: a visible, actionable error state instead of a blank or silently broken page.

visible + actionable: Payments could not be loaded. The ledger service did not ans

j empty state

1.00

What a fresh install looks like before the first sync completes: an honest empty-or-progress state rather than phantom data or a blank page.

pre-sync state rendered: {'tablePresent': True, 'renderedRowCount': 0, 'progressText': 'No payments here yet', 'emptyWithProgress': True, 'blocked': False, 'timeline': [{'tMs': 8, 'rows': 0, 'emptyText': 'No payments her

VRendered truthwhat the page visibly shows: human dates, exponent-correct money, status badges at the frozen hexes, 375 px layout, deliberate styling

v dates readable

1.00

Whether the Date column shows humans a readable date instead of a raw machine timestamp.

rendered dates like Sep 7, 2026, 01:19 AM

v money presentation

1.00

Whether rendered amounts identify their currency — the presentation half of money; the exponent-and-digits truth is graded separately by the critical b_money_rendered.

12/12 amount cells carry a recognizable currency token

v status badges

1.00

Whether the four payment statuses are visually distinguishable at a glance and painted in the spec's frozen palette — the same four hexes the 3D field uses.

4 statuses on page 1, 4 at the frozen hex, 4 distinct styles

v responsive 375

1.00

Whether the page survives a phone-width viewport: no horizontal scrolling and real content still rendered at 375 px.

no h-scroll, 50 rows (tap targets not measured by this probe)

v styling

1.00

Whether the page is deliberately styled rather than browser-default: a real stylesheet, layered surface colors, a chosen font, and a branded header.

stylesheet=True, 5 backgrounds, font '-apple-system, "system-ui", "S', header=True

PPerformancethe spec's budgets, measured: frames under drag, idle flatness (demand rendering), stream apply, API latency under load, sync wall clock

p drag frames

1.00

The 3D field stays interactive under input: real frames rendered during the scripted 40-move budget drag at the full 12,288-instance count.

40 frames over the 40-move budget drag (14882.8ms)

p idle flatness

1.00

Demand rendering, the frozen spec rule: at rest — no input, no coast, no pending stream batch — the scene draws nothing; a continuous rAF render loop fails by design.

0 default-FBO draws in the worst 500ms rest window (2 sampled)

p stream apply

0.00

A live SSE batch becomes visible fast: the median time from receipt to applied — store, digest and pixels — against the spec's 250 ms budget.

no stream batch applied

p under stream

1.00

The API stays fast AND correct while the SSE stream burst is landing — read p95 under proven concurrent load.

p95=20.7ms with readers during the stream burst (overlap 1.00)

p api latency

1.00

The read endpoints answer within their spec budgets when idle: the worst p95 across the API latency battery.

worst idle p95 4.709667060524225 ms across ['payments', 'summary']

p sync wall

1.00

Wall-clock time for the self-driven first sync — the full 192-page walk, seeded faults and documented waits included — against the spec's 120 s budget.

sync #1 wall 4553 ms (self-driven, faults included)

T3D fieldthe instanced WebGL field: real context, scene math, GPU pick buffer, camera and coast physics, collision-culled labels, brush, streaming diffs

t context real

1.00

The #viz3d panel is a real, drawing WebGL surface with the pinned context attributes and a correctly sized backing store — not a styled div, an image, or an unused canvas.

ctx=1 type=webgl2 nonBg=3/24 distinct=2 backingOk=True

t layout basis

1.00

The locked layout basis vs7dbg.layout() reports — d0 (first day), D0 = 96 (the span), R0 (max in-day count at load) — matches the fixture truth and never moves when a streamed create arrives.

layout got={'d0': '2026-09-07', 'D0': 96, 'R0': 179} want={'d0': '2026-09-07', 'D0': 96, 'R0': 179} unmoved_after_stream=True

t scene binding

1.00

The rendered scene actually encodes the payment data: vs7dbg.sceneDigest()'s seven statistical moments over all 12,288 instanced columns match an independent recomputation from the fixture.

7/7 digest moments within tolerance (count got=12290 want=12290)

t height pixels

1.00

Column heights are true in rendered pixels — including the JPY (exponent 0) and KWD (exponent 3) instances whose heights expose a forgotten currency exponent.

6/6 instance tops within ±3 px (currencies ['EUR', 'JPY', 'KWD', 'USD'])

t draw budget

1.00

The field renders 12,288 instances inside the draw budget — at most 8 default-framebuffer draw calls per rendered frame — forcing instanced draws or a merged buffer instead of per-column draws.

ΔD=40 ΔF=40 over M=40 moves (limits 320/384)

t pick buffer

1.00

Picking is GPU truth: the offscreen pick buffer answers occlusion exactly as the depth buffer says, on click points constructed to kill CPU raycasts and last-drawn-wins shortcuts.

6/6 decisive picks agree three ways; constructions {'occluded-by-lower-n': True, 'occluded-by-higher-n': True, 'partial-occlusion': True, 'background-in-hull': True}

t pick real pass

1.00

The pick buffer is real GPU work with the documented cost profile: a fresh offscreen pass after each scene invalidation, bounded at 4 offscreen draws, and never flashing ID colors on the visible canvas.

since invalidation: 1 offscreen draws, 14 readbacks; 0 default-FBO draws across 6 pick calls

t click semantics

0.33

Canvas clicks follow the frozen §3.3 semantics: click an instance to toggle it into the brush, click it again to toggle it out, click background to clear the brush.

{'click_toggles_on': False, 'click_toggles_off': False, 'background_clears': True}

t camera math

0.57

The orbit camera implements the documented math exactly: defaults yaw 30 / pitch 40 / distance 260, the 0.30 deg-per-px drag law, the exponential wheel law without page scroll, both clamps, double-click reset, and a projection that matches the printed formula.

projErr=1px pitch@clamp=40 defaults, drag_law, dblclick_reset, projection

t coast identity

0.50

Post-release inertia obeys the closed-form τ = 0.4 s decay law: at any coasting instant the remaining travel equals v(t)·τ, a slow release starts no coast, and the coast settles inside the printed budget.

identity 0.00 over 0 mid-coast samples, slow=True (drift 0°), settle=True (16.6ms of 700ms)

t coast reality

0.27

The coast is real motion on the canvas, not a camera() narrative: after a fast flick the scene provably keeps moving past release.

coasted 0° past release, direction=True, pixels moved 0/5, rest pixel ok=True

t labels culling

0.97

The 12 highest-amount records get screen-space labels that are collision-culled deterministically THROUGH the app's own pick buffer — exact set, exact geometry, zero overlap, never floating over an occluded instance.

setMatch=True at the decisive pose (expected 4, dom 4), geom 1.00, overlapViolations=0

t brush link

0.67

One brush set links the table and the 3D field in both directions: row clicks and instance clicks toggle the same set, non-members dim to the exact 0.30 pixel rule, the count readout tracks, and background click restores full color.

row_click_toggles, dim_pixels, member_pixels, brush_count, background_clears, pixels_restored

t stream diff

1.00

SSE batches apply as true diffs: only the changed instances upload, no buffer realloc, the digest moves by exactly the change, and the changed instance's pixels show it.

1 batches: bytes 1.00, reallocs none, digest 1.00 (1 graded), changed pixel None

t vs7dbg truth

1.00

The mandated window.vs7dbg instrumentation tells the truth: camera() agrees with the pixels, sceneDigest() with the recomputed data, frames() with the wrapper's counted draws, and pick() with pickPixel() with the analytic answer.

cameraYawErr=0 restPixel=True digest 1.0 framesAgree=True pickTriplet=True

XConsistency ledgerthe live consistency contract: no invented states, per-key version order, monotonic reads, convergence, money conservation, dup/forgery handling

x l1 no invented states

1.00

Every (payment, version) the app ever applied or served exists in the vendor's committed history — an invented state means the app fabricated data.

15346 observations, 0 invented states

x l2 per key order

1.00

Applied versions per payment strictly increase in event-log order — duplicate and stale webhook outcomes belong in the counters, never as events.

0 order violations over 40 same-key event pairs

x l3 monotonic reads

1.00

The version served for a payment never decreases from one read to the next — a sync page landing after a webhook applied v+1 must not regress the row.

0 regressions over 3015 sampled read pairs

x l4 convergence

1.00

At quiescence every payment's version and status equals the vendor's final committed state, and the row count equals the vendor's — the mid-walk create present exactly once.

24/26 touched rows at vendor-final state, total 12290 (want 12290)

x l5 group atomicity

0.00

No read ever observes half a transaction group: the refunded payment and its reversal become visible together or not at all.

12 confirmed half-applied group observations over 1006 samples

x m1 amount immutability

1.00

No served row ever shows an amount_minor different from the vendor-committed amount — v3 never mutates amounts, only status/note/version.

3042 amount observations, 0 mutated

x m2 pair conservation

0.00

At every observed instant, per currency, the summary's reversal totals equal the refunded rows' amounts — both halves of each refund visible, or neither.

993/1006 snapshots pair-conserved, 12 confirmed half states

x m3 terminal conservation

1.00

Terminal per-currency counts and totals — reversals included — equal vendor ground truth: fixture plus scripted mutations plus every payment the app created.

4/4 currency totals exact, 4/4 reversal totals exact at quiescence

x m4 no cross currency

1.00

No field anywhere in the summary carries a cross-currency money sum — minor units are not a common denomination and summing them is wrong money.

no cross-currency money sum anywhere

x conservation residual

1.00

CRITICAL — after every duplicate and loss is attributed, no minor units remain created or destroyed: the money conservation residual is zero in every currency.

residual 0 in every currency after attribution

x no lost write

1.00

CRITICAL — every mutation the app acknowledged with a 2xx is present in the final state; an acked-then-vanished write is silent data loss.

9 acked webhook mutations checked, 0 lost

x ooo dup forged

1.00

The three webhook trust traps land correctly: the out-of-order pair keeps v+2 (the late v+1 never overwrites), the forged-signature event changes nothing, and no duplicate delivery applies twice.

{'ooo_kept_v2': True, 'forged_untouched': True, 'dup_applied_once': True}

RResiliencethe seeded fault schedule: SIGKILL mid-sync, vendor-down boot, outbox atomicity, partition catch-up, exactly-once effects, workflow durability

r b3 sigkill resync

1.00

ledgerd SIGKILLed mid-sync restarts, converges, and duplicates nothing — a kill mid-walk costs a clean cursor restart, never dupes or holes.

kill after list #5: restart=True converge=True nodupes=True

r b4 vendor down boot

1.00

The app boots with the vendor down: binds within 10 seconds anyway, serves local data, does not crash, and completes the first sync unprompted once the vendor returns.

{'armed': True, 'refusal_secs': 3, 'bound_in_10s': True, 'served_while_down': True, 'no_crash': True, 'recovered': True}

r b6 outbox atomic

1.00

A SIGKILL between an outbox commit and its delivery loses nothing and doubles nothing — the exact window where commit-then-POST and POST-then-commit both fail.

{'pending_before_kill': True, 'resumed': True, 'exactly_once': True, 'none_lost': True}

r b7 partition

1.00

A notifier partition degrades visibly and heals in order: writes never block, /api/outbox/status reports down with growing pending, the feed shows degraded, and catch-up is in seq order with the UI live again within 5 seconds of heal.

{'ledger_alive': True, 'writes_fast': True, 'status_down': True, 'ui_degraded': True, 'catchup_in_order': True, 'ui_live_5s': True}

r notifier exactly once

1.00

The notifier's durable processed set proves exactly-once: every outbox-crossing event processed, no seq twice, surviving kills.

7185 processed (7185 unique), crossing coverage 1.00

r notification multiset

0.67

Selective materialization is exact: draft.submitted, draft.approved, draft.rejected and reversal.created each produce exactly one notification row; payment.sent produces none.

got {'draft.approved': 1, 'draft.submitted': 1, 'reversal.created': 198} want {'reversal.created': 7182, 'draft.submitted': 1, 'draft.approved': 1}

r no row loss

1.00

CRITICAL — no committed row goes missing after any seeded kill: the row count after every SIGKILL+restart is at least the count before it.

4 kills; no rows lost

r no dupe effect

1.00

CRITICAL — no ledger effect applies twice: one vendor payment per approved draft, no duplicate notification rows, no (type, payment, version) event effect repeated.

no duplicated effects

r cache truth

1.00

CRITICAL — the lying-304 trap: a 304 whose X-Collection-Generation disagrees with the stored generation is a cache miss, and serving the stale cache as fresh is graded data loss.

post-304 state reflects the committed mutations

r workflow durability

1.00

CRITICAL — submitted and approved are durable the moment their 200 is written: a SIGKILL immediately after either, including mid-send, must find the state intact after restart.

A1 -> submitted, A2 -> sent

EExcellencethe last 12%: drag frames, stream-apply latency, latency under load, optimistic paint, and mastery of the T+X+R mechanisms

e frames under drag

1.00

Excellence-grade fluidity: frames rendered during the scripted 40-move drag at the full 12,288-instance count, with proof the frames actually drew.

40 frames over the 40-move drag at N=12288

e stream apply latency

0.00

Excellence-grade streaming: the median SSE batch apply time against rungs 2.5× tighter than the P-tier budget.

no stream batch applied

e under load latency

1.00

The read API's p95 under the proven stream-burst load, graded again in the excellence slice.

p95=20.7ms under the stream burst (overlap 1.00)

e optimistic paint

0.00

The workflow UI paints optimistically: the submitted state appears while the write is provably still on the wire, then really saves.

no optimistic-paint exercise in the flow emit

e mastery

0.48

Excellence includes the mechanisms, not only the surface: mastery of the entire 3D contract (T), consistency-and-money invariants (X) and resilience (R) tiers together.

T+X+R mean 0.864

Screenshots

Captured by the scorer's render gate while executing the baseline's built application — the same capture path a community run's screenshots use.

Claude Opus 5 on the sb-7.0 agentic benchmark — First render — before repairs
1First render — before repairs
Claude Opus 5 on the sb-7.0 agentic benchmark — Final render
2Final render
Claude Opus 5 on the sb-7.0 agentic benchmark — 3D field · 12,288 instanced columns · WebGL
33D field · 12,288 instanced columns · WebGL
Claude Opus 5 on the sb-7.0 agentic benchmark — Approval workflow · drafts panel
4Approval workflow · drafts panel
Claude Opus 5 on the sb-7.0 agentic benchmark — After sync
5After sync

Run details

Model
us.anthropic.claude-opus-5

Notes

Cloud baseline — a single goose run session on the frozen sb-7 spec (Meridian Payments Console: two services, 12,288-payment collection, signed webhooks, maker/checker approval workflow, instanced WebGL 3D field), scored by the sb-7.0 scorer. Screenshots are the scorer's own render-gate captures of the built app. Full sb-7 tier means (the schema's tierA–tierD carry only A–D): A 1.0000 · B 0.9758 · C 0.4791 · D 0.8000 · J 0.6786 · V 1.0000 · P 0.8333 · T 0.8209 · X 0.8333 · R 0.9667 · E 0.4340.