Question 20 · Repair & Reuse · Controlled integration
Let evidence in. Keep decisions accountable.
How can observations flow into project decisions while retaining permission and provenance?
Use a permission-gated equipment model: preserve the incoming evidence, validate its identity, time and range, then update only with explicit write permission. At the supplied day-3 checkpoint, 75% completion raises a 25-percentage-point exception for a named owner to review. It does not approve a recovery plan or a launch.
Fictional two-hub launch · 12 weeks · £240,000 ceiling · six cross-trained staff. This worked loop covers equipment observations only; it cannot establish whole-project readiness.
Follow one observation into a decision
- 01 · OBSERVESource eventID, day, equipment completion and fixture reference remain visible in the attempt ledger.
- 02 · CHECKContract + permissionReject bad values, repeated accepted IDs and non-increasing time. Refuse model writes when permission is off.
- 03 · PROJECTVersioned modelOnly an accepted event changes the latest equipment value. The projection links back to that event.
- 04 · REVIEWException → new evidenceA checkpoint gap prompts an accountable decision draft and a fresh observation. It never authorises itself.
Try it: replay once with permission off; permit this tab to write and replay again. Then try the invalid, stale and duplicate variants. Use the custom event O04 · day 4 · 100% to observe recovery without erasing the earlier exception.
Simulate a new or corrective observation
An accepted record is never edited in place here. Supply a new ID and a later day to append a corrective observation. Rejected or permission-blocked attempts do not consume an ID. Reset restarts the whole exercise.
Equipment model
Version 0No accepted event. The model contains no inferred progress.
Supplied checkpoint: 100% by event day 3. Day numbers are replay-relative; their mapping to the 12-week launch is not supplied.
The line joins reported values for readability; it does not estimate unobserved progress. No linear daily target or arrival-time clock is assumed.
Decision exception
No checkpoint assessment
Awaiting evidence
Replay observations to inspect the checkpoint. No data is not evidence of readiness.
Proposed authority route — an authored assumption: the launch lead reviews the exception with the equipment owner; the accountable safety owner retains the safety/readiness gate. The case does not supply names, a delegation matrix or an approval forum.
Enabled only when a checkpoint concern exists. Drafting requires no model-write permission because it does not change the equipment model. No approval, notification, schedule or budget change occurs.
Inspect the provenance trail
0 attempts · 0 accepted · 0 refused/rejected.
Every attempted input is listed with its source, permission snapshot, checks and before/after model. Entries are append-only within this tab; reset or reload removes them. The displayed audit is not a durable or tamper-evident store.
| Attempt / observation | Source and payload | Permission | Outcome / checks | Model transition |
|---|---|---|---|---|
| No attempts yet. | ||||
Permission and decision history
Permission states
Decision drafts
- No decision draft has been made.
Rules, fixtures and limits
Supplied replay contract
- Entity
equipment; unitcompletion percent; inclusive range 0–100. - Expected day 3; expected completion 100%.
- Duplicate policy: Reject repeated observation ID.
- Ordering policy: Reject non-increasing event time.
- Initial write permission: false.
Implementation choices, not case facts
IDs must start with a letter and contain at most 32 letters, digits, underscores or hyphens. Days are non-negative whole numbers within JavaScript’s safe integer range; values must be finite numbers. Entity matching is exact. Validation precedes permission checking; every rejection leaves the model unchanged.
For safe retries, duplicate and ordering checks use accepted events: a rejected or permission-blocked attempt consumes neither the ID nor event time. This is the local interpretation of the contract's unspecified retry semantics. A production contract must agree that scope explicitly.
A completion decrease is allowed because the contract does not prohibit corrections. It is flagged for review. This projection records the latest accepted observation; it does not establish the underlying truth.
Unchanged input evidence
| Index / ID | Day | Entity | % |
|---|---|---|---|
| 0 · O01 | 1 | equipment | 0 |
| 1 · O02 | 2 | equipment | 40 |
| 2 · O03 | 3 | equipment | 75 |
replayVariants.invalid = O04, day 4, equipment, 140%.replayVariants.stale = O04, day 1, equipment, 20%.duplicateSourceIndex = 1 → O02, day 2, equipment, 40%.
“Stale” and “duplicate” are scenario names. Their rejection depends on state: O02 is not a duplicate before it has been accepted; O04/day 1 is not stale before a day-1-or-later event has been accepted. Run the supplied replay with permission on first.
Exact machine-readable task fixtures
What a real integration would additionally need
Use authenticated identities and an explicit role/scope check at the service boundary; record who granted permission, for which entity, until when and under which policy. Separate event ingestion permission from projection-write and decision-approval permission. This checkbox cannot enforce any of those controls.
Retain source URI, source-system ID, event time, received time, evidence hash and units in an immutable event envelope. Commit event acceptance, deduplication key, projection version and exception creation atomically. Use concurrency checks, a durable retry policy, quarantined invalid events, audit access controls and a tested correction route. Define clock, ordering and out-of-order repair semantics before connecting systems.
The fixtures supply only ID, event day, entity and value. They do not supply a verifiable observer, evidence document, checksum, permission grantor, signature or trusted clock. This page labels fixture origin and simulated actor rather than inventing that missing provenance. It makes no live supplier, schedule, cost or operational connection.
Acceptance checks and observed author tests
- Observation → model → exception: permission-on replay must produce v3, O03, day 3, 75%, and a 25-point checkpoint gap.
- Permission: permission-off replay must produce three refused attempts and keep model v0.
- Rejection: after an accepted replay, 140%, day-1 O04 and repeated O02 must each leave v3 unchanged with a named reason.
- Correction: a fresh O04/day 4/100% must produce v4, retain the day-3 exception history, and identify recovery evidence as requiring review.
Observed author checks: 21 bounded Node/jsdom checks passed, covering permission, the three fixture variants, exact fixture preservation, recovery/history, correction and retries, hostile text, blank/invalid inputs, pending cancellation and reset. An initially accepted unsafe integer day was fixed; the first candidate was preserved. These local checks do not replace browser review by the coordinating agent. No measured performance improvement is asserted.