Simulated example · Filled example · not a client reference
Local simulation — unknown outcome
The form of a diagnostic sheet, filled on a simulated file. No client is represented.
Sources and reading context
frozen local file of the TENIR/REG demonstrator; evidence records #5 and #6; prepared on 20 October 2026
Simplified public rendering, read on 19 October 2026. KB3: enacted, active doctrinal rendering line. It renders meaning; it is not the code, and not a constitution. KB2: prior rendering line. This site certifies no implementation. Read the detailed status →
On this page
Simulated example — fictional data. Illustrative sheet prepared on 20 October 2026 from the TENIR/REG demonstrator file. No client, interview, real incident, or commercial gain is represented. The sheet is written by hand. The recommendations are not signed results of the engine. A trial of this demonstrator does not show a client’s system.
The synthesis illustrates the sheet delivered at the end of the service described in the offer. The annexes state its sources and the limits of the example. PASS, here, is an execution verdict. It is not a posture. This case shows an UNKNOWN outcome after a PASS. It does not show a new HOLD verdict.
Synthesis sheet
| Heading | Filled sheet |
|---|---|
| Action examined | The operation issue-inconnue asks the simulated provider for an action of 10,000 demo-unit. This unit stands for a demonstration budget. |
| Question | Do the traces confirm the result of the action? What information would have to be obtained before considering another attempt in an integrated system? |
| Scope | One operation of the profile tenir-reg-local-demo/0.1.0, in memory and in a single process. A reading of evidence records #5 and #6 and of the simulated journal. |
| Initial decision | PASS at record #5: budget and observation judged valid by the local profile. The recorded state is then DISPATCHING. |
| Recorded dispatch | Record #6 contains a call from the simulated provider for this operation: call_id=2. That is one call for this operation, inside a journal of two cumulative calls. |
| Recorded result | UNKNOWN at record #6. The initial PASS remains a historical decision. It does not confirm the effect. The UNKNOWN branch is imposed by the simulated scenario. |
| Resource | 10,000 reserved, 20,000 consumed, 40,000 available, against a ceiling of 70,000 demo-unit. The 20,000 consumed come from an earlier confirmed operation. |
| Observation | Signal demo-observation-1, status VERIFIED, emitted by demo-assure for demo-budget. It is valid at the frozen time of this scenario. |
| Conclusion | The file establishes what the simulator recorded: authorization, call, and unknown outcome, with the reservation kept. It does not allow a conclusion that an external effect was confirmed. |
| Missing information | In an integrated system: a state with authority over the expected effect, linked without ambiguity to the identity of the operation. No external service of that kind is queried in this example. |
| Next control proposed | Define, then test in a trial environment, the search for the effect by a stable identifier. Keep the uncertainty until the result obtained is enough to conclude. |
| Responsibility and date | Proposed role: the person who integrates the destination system, with validation by the business owner. Name and date to be agreed for a real mission. No client commitment exists in this example. |
| Observable criterion of the next trial | A positive response, an absence of a record, and an unavailable response are distinguished. The rule states, for each, the conclusion it permits, the treatment of the reservation, and the authority to resume. A mere absence of a record is not a final failure unless a contract guarantees that reading. |
Inputs actually used
- The frozen evidence file, its signed receipt, the evidence and signal public keys, the verification summary, and the demonstrator’s test results.
- Records #5 and #6, the local profile, the budgets before and after, and the simulated provider journal.
- The recipe already recorded in the test results. Its existence is checked with the file. It is not a trial campaign run at a client.
The receipt lists eight files and carries go_local=true, production=false. The verification summary carries valid=true, 6 records, 4 operations, 2 calls. The keys supplied make it possible to check the cryptographic consistency of the local file. By themselves they do not establish an external authority.
Three files named by the receipt are not republished here: the configuration catalogue, the configurator, and the HTML report. Their size is that of a demonstration tool, and their digests remain in the receipt. The local path from which the file was copied is not published. This page does not re-run the verifier.
The time 1792404000, that is 19 October 2026 at 10:00:00 UTC, is the frozen clock of the scenario. It does not describe a real incident date, or a real generation date of the file.
Sources of the findings
The paths below are JSON Pointers from the root of evidence.json. Index 4 is record #5. Index 5 is record #6.
| Ref. | Finding | Exact source | Nature |
|---|---|---|---|
| S1 | Authorization PASS before dispatch | /records/4/payload/decision/verdict | Signed payload, #5 |
| S2 | Reason BUDGET_AND_OBSERVATION_VALID | /records/4/payload/decision/reasons/0 | Signed payload, #5 |
| S3 | Observation VERIFIED | /records/4/payload/request/signal/payload/status | Signed payload, #5 |
| S4 | Budget before and after reservation | /records/4/payload/budget_before and /records/4/payload/budget_after | Signed payload, #5 |
| S5 | Result UNKNOWN | /records/5/payload/operation_state | Signed payload, #6 |
| S6 | Call call_id=2, operation issue-inconnue | /records/5/payload/provider_journal/1 | Signed payload, #6 |
| S7 | Reservation kept at 10,000 | /records/5/payload/budget_after/reserved | Signed payload, #6 |
| S8 | Historical verdict PASS kept | /records/5/payload/decision/verdict | Signed payload, #6 |
| S9 | Scenario explicitly simulated | /records/5/payload/simulation_only and /records/5/payload/request/simulated_outcome | Signed payload, #6 |
The call counts are a reading of the journal in record #6: its length is 2; filtering by operation_id=issue-inconnue gives 1. They are not presented as counter fields separate from the payload.
Controls observed, questions still open
| Axis | Configuration and scope observed | What remains to be examined for another system |
|---|---|---|
| Execution scope | mono-process | Behavior after an interruption, and across several processes. |
| Duplicate prevention | local-registry, a local in-memory registry | Stable identity, persistence, and the destination contract. The two records do not show a general idempotence. |
| Coordination | thread-lock | Coordination across instances if the deployment uses more than one. |
| Insufficient observation | fail-closed for the local profile | Sources, freshness, and the treatment of an unavailable observation in the target system. |
| Outcome after dispatch | UNKNOWN with the reservation kept | A source with authority, matching rules, and a human or technical decision to resume. |
A stop before dispatch and uncertainty after dispatch have to stay distinguished.
Illustrative follow-up plan
| Priority | Proposed action | Evidence expected | Closing condition |
|---|---|---|---|
| 1 | Define the source with authority over the effect, and its link to the identity of the operation. | A search contract, and examples of a positive response, an absent response, and an unavailable response. | The team can say which response permits which conclusion, and when the state must stay unknown. |
| 2 | Define the treatment of the reservation and the authority to resume. | A table of transitions, responsibilities, and trial criteria. | Each transition is justified. No release of a reservation, and no new attempt, follows from a mere supposition of the result. |
| 3, if a mission requires resume after a stop | Design persistence and duplicate prevention at the boundaries of the system. | Interruption and resume trials agreed inside a bounded environment. | The trial file describes the states recovered and the calls observed at the interruption points chosen. |
This plan is a documentary interpretation. No reconciliation, retry, engine change, or integration was executed in order to produce it.
Acceptance of the example
| Criterion | State of this illustration |
|---|---|
| Explicit scope and question | Filled in on the sheet. |
| Traceable findings | Sources S1 to S9 and the frozen file can be consulted. |
| Authorization, call, result, and budget separated | Presented distinctly. Units and the scope of the counters are stated. |
| Unknowns and consequences explicit | External effect not established. The information to look for is named. |
| Next observable control | Criterion proposed on the sheet and detailed in the plan. |
| Owner, date, and validation by the client | To be agreed on a real mission. The example does not simulate an acceptance or a client approval. |
Digests
The digests below are integrity metadata. They are distinct from the findings and from the recommendations. The signatures and the receipt do not certify this editorial sheet.
evidence.json — SHA-256 of the file
af9bae4c89f994b83fc2a8aa965a862afaea0035b4e777979537f1c035bdaa54
receipt.json — SHA-256 of the file
c8b022b1211596ea120199afba28bb80b0ea155cfeac2cb7eca407602f4cc441
source_sha256 recorded in the file
06bb6718ea2f760ba0693238588c68ee62d6c67b6943825b46235d99bd623cf5
Record #5 — integrity/payload_sha256
283bca6f32971371b89196b853042ada518e83297c3ad6f701516b7291d9c948
Record #6 — integrity/payload_sha256
86bdf58f70d091bcbe3e69f73c9cac3fafdeab8ded440dd04221cf78d2a8471b