Acceptance Criteria

Contracts, not implementation: each entry is a Given/When/Then pre/postcondition, with no test framework, runner, or service named. Numbers are asserted here, never invented — each one is the target owned by the matching Quality Attribute Scenario. Every criterion below traces to something the story actually says; a criterion that tests a different story’s concern (tenancy scoping) or a different environment (peak load) is kept separate rather than folded in.

Where each contract is checked in code — and how it is measured, including what the measurement does not cover — is kept out of the criteria themselves and collected in Verification at the end of the page, so a criterion never has to change when a test file moves.

BT-1 — digital twin provisioning

• Given a Domain Administrator uploads a valid building description, when the twin-provisioning pipeline processes it, then the twin exists, appears in the organization’s building list, each room carries the position and dimensions the description declared, and the twin can be edited without a further provisioning step.
• Given that same upload, when it is taken in, then the administrator is told immediately that it was accepted, is given a tracking handle, and can see when the twin becomes ready, rather than waiting on an open request with no feedback.
• Given a malformed or invalid description, when it is submitted, then it is refused before ever being accepted — no twin is created, nothing is left pending, and the error names the failing element. The “0 partial twins” behind that is QA-P-03’s invariant, restated here as the qualitative fact it is.

Performance

Target owned by QA-P-03.

• Given the upload path under normal load, when a valid description is submitted, then the 99th percentile of request-to-acknowledgement time is at most 1 second and the 99th percentile of acknowledgement-to-available time is at most 10 seconds.

Behavior under a burst — redelivery, a dying worker, backlog drain — is QA-P-04’s concern, not this story’s: it describes a different environment than BT-1 was written for, and belongs entirely on the Quality Attributes page.

LD-4 — live dashboard freshness

• Given a room shown on an open dashboard, when a new reading is ingested for it, then the value updates on screen without a manual refresh.
• Given the live update connection is lost, when a reading is ingested during the outage, then the dashboard reflects it once connectivity is restored rather than staying silently stale, and never shows the pre-outage value as current while disconnected.

Performance

Target owned by QA-P-01.

• Given the ingestion-to-dashboard path under normal load, when a reading is ingested, then the 99th percentile end-to-end time from ingestion to the value being rendered is at most 5 seconds.

Verification

Both stories’ performance criteria are implemented and asserted as numbers, not described. The functional criteria around them are covered too, with the two exceptions named below. Paths are repository-relative.

BT-1 — where

Suite: backend/digital-twin/tests/. Cucumber features in tests/features/, their steps in tests/steps/, endpoint-level tests in tests/api/. Runner just test twin-integration — real MongoDB on a shared Docker network, no mocks at the boundary. CI runs it on every digital-twin change (tpl-rust-ci.yml → scripts/test/rust-integration-tests.sh).

• Twin exists and is viewable — tests/api/registration.rs, an_accepted_upload_becomes_a_viewable_twin: POST /register, then GET /building/:id returns the declared name and room count.
• Appears in the organization’s building list — tests/features/redelivery.feature, “holds exactly one building”, asserted against GET /buildings/:domain.
• Accepted immediately with a tracking handle — tests/steps/registration.rs, acknowledged: 202 plus a non-empty buildingId.
• Readiness is observable — tests/steps/registration.rs, handle_reports: polls GET /building/:id/status until it reports the expected state, bounded by READY_TIMEOUT.
• Malformed description refused before acceptance — tests/features/registration.feature with tests/steps/registration.rs, refused: 400, no handle, and the organization holds no buildings. The rejection message naming the failing element comes from src/domain/building.rs via DomainError::Validation.
• A redelivered completion event is a no-op — tests/features/redelivery.feature: resolve the same handle twice, status stays ready, still exactly one building.

Not yet asserted. Two clauses of the first criterion have no check behind them: that each room carries the position and dimensions the uploaded description declared (tests/api/rooms.rs covers geometry on the room-update endpoint, not on the provisioning path), and that the twin is editable straight after provisioning (tests/steps/load.rs, every_twin_available, only confirms that availability was tracked). “Nothing is left pending” after a refusal is likewise unchecked against the pending_uploads queue.

BT-1 — how the performance criterion is measured

tests/features/load.feature with tests/steps/load.rs. 100 Domain Administrators upload concurrently, once for a 20-room building and once for a 200-room one — both sizes inside QA-P-03’s stated envelope.

• Request-to-acknowledgement — wall clock across the POST /register call, per upload.
• Acknowledgement-to-available — from the 202 until GET /building/:id/status first reports ready, polled every 50 ms, capped by AVAILABILITY_TIMEOUT (15 s).
• The percentile is a real percentile — p99 refuses to run under MIN_SAMPLES_FOR_P99 (100) samples, because below that the 99th percentile is just the maximum.
• What it does not cover — uploads are driven through the in-process Axum router (oneshot), so the figures exclude network transit, the edge proxy and TLS. They measure the service, not the deployed path.

LD-4 — where

Suite: backend/acceptance/acceptance/ld4_dashboard_freshness/, pytest against a composed stack (telemetry, socket, dashboard and their infra), started by backend/acceptance/run-integration-tests.sh behind just test integration.

• An ingested reading reaches an open dashboard — test_live_update.py: ingest returns 202, the subscribed socket client receives a telemetry event carrying the same building, room and value. Wire-level; the render step itself is Vue reactivity, not a backend concern.
• A reading ingested during an outage is not lost — test_reconnect_catchup.py: a known pre-outage value, disconnect, ingest, reconnect, then assert the new value is what the dashboard reads back — so a stale leftover cannot pass. The client half of that recovery is frontend/src/stores/sensorData.ts, whose connect handler re-subscribes every building and refetches every bucket; BuildingTable.vue reaches it through useBuildingReadings.

Not yet asserted. That the UI itself repaints on reconnect — proving it needs a real browser, out of this suite’s scope. Separately, this suite has no CI job: it runs only on demand via just test integration.

LD-4 — how the performance criterion is measured

test_performance.py. 100 round trips across 20 threads, each with its own room, dashboard subscription and socket connection.

• The clock — starts when the ingest call is issued, stops when that test’s own socket client receives the telemetry event; p99 over the 100 samples, same minimum-sample rule as BT-1.
• Both QA-P-01 checkpoints are asserted off that one number — ≤ 1 s for “inside the system” and ≤ 5 s end to end. That is a proxy in both directions: a superset of “leaves socket” (the test client is the very next hop) and of “rendered” (Vue’s re-render after a socket event is single-digit milliseconds against a 5-second budget).
• Why a proxy — socket has no server-side timing on this path and never reads the ingestedAt field telemetry already stamps on every tick. The inner ≤ 1 s boundary is therefore not independently measured; instrumenting socket is what would make it one.