Skip to content

Commit f9ef2b0

Browse files
BryceWDesignBryceWDesign
authored
Create IXS-REVIEW-WALKTHROUGH.md
1 parent de53b2b commit f9ef2b0

1 file changed

Lines changed: 281 additions & 0 deletions

File tree

‎docs/review/IXS-REVIEW-WALKTHROUGH.md‎

Lines changed: 281 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,281 @@
1+
# IX-Style Review Walkthrough
2+
3+
## Document ID
4+
5+
IXS-REVIEW-WALKTHROUGH
6+
7+
## Status
8+
9+
Draft review baseline.
10+
11+
## Purpose
12+
13+
This document gives a reviewer a practical walkthrough for inspecting one
14+
IX-Style scenario result or exported review-artifact package.
15+
16+
It exists because review quality drops fast when a repo has strong internals but
17+
no clear inspection order.
18+
19+
---
20+
21+
## Review Goal
22+
23+
A good IX-Style review should answer five questions quickly:
24+
25+
1. what scenario was executed
26+
2. what dominant posture resulted
27+
3. what happened to the candidate command
28+
4. why did the system choose that outcome
29+
5. can the evidence chain be trusted as untampered
30+
31+
---
32+
33+
## Best Review Order
34+
35+
When reviewing one exported package, open files in this order:
36+
37+
1. `manifest.json`
38+
2. `operator_safety_summary.json`
39+
3. `mission_health_snapshot.json`
40+
4. `decision_receipt.json`
41+
5. `evidence_package.json`
42+
6. `evidence_bundle.json`
43+
7. `verification_result.json`
44+
45+
This order is intentional.
46+
It moves from human summary toward machine detail.
47+
48+
---
49+
50+
## Step 1 — Manifest
51+
52+
Open `manifest.json` first.
53+
54+
Confirm:
55+
56+
- scenario ID
57+
- scenario name
58+
- passed status
59+
- final outcome
60+
- dominant safety posture
61+
- list of files present
62+
63+
If the manifest already looks inconsistent with the scenario purpose, the review
64+
has found a serious problem early.
65+
66+
---
67+
68+
## Step 2 — Operator Safety Summary
69+
70+
Open `operator_safety_summary.json`.
71+
72+
Look at:
73+
74+
- headline
75+
- decision rationale
76+
- operational why
77+
- authority statement
78+
- recovery statement
79+
- operator focus
80+
- timeline markers
81+
- review significance
82+
83+
This file tells you whether IX-Style can explain itself to a human without
84+
making them reverse-engineer the whole state machine.
85+
86+
---
87+
88+
## Step 3 — Mission Health Snapshot
89+
90+
Open `mission_health_snapshot.json`.
91+
92+
Confirm:
93+
94+
- mission phase
95+
- dominant safety posture
96+
- containment status
97+
- review significance
98+
- authority summary
99+
- trust summary
100+
- active fault summary
101+
- recovery summary
102+
- recent events
103+
104+
This file tells you the current operational picture the system claims to be in.
105+
106+
---
107+
108+
## Step 4 — Decision Receipt
109+
110+
Open `decision_receipt.json`.
111+
112+
Confirm:
113+
114+
- decision ID
115+
- candidate action summary
116+
- final outcome
117+
- final authoritative source
118+
- safety posture
119+
- triggered constraint IDs
120+
- recovery-gate result
121+
- rationale summary
122+
- command delta
123+
124+
This is the main answer to:
125+
> what happened to the command and why
126+
127+
If this file is weak, IX-Style is weak no matter how many other artifacts exist.
128+
129+
---
130+
131+
## Step 5 — Evidence Package
132+
133+
Open `evidence_package.json`.
134+
135+
Confirm:
136+
137+
- generated event IDs
138+
- expected outcomes
139+
- actual observed outcomes
140+
- trust transitions
141+
- fault transitions
142+
- mode transitions
143+
- pass/fail result
144+
145+
This is where you see whether the scenario produced the expected supporting
146+
evidence around the main decision.
147+
148+
---
149+
150+
## Step 6 — Evidence Bundle
151+
152+
Open `evidence_bundle.json`.
153+
154+
Confirm:
155+
156+
- bundle ID
157+
- head chain hash
158+
- item count
159+
- ordered bundle items
160+
- presence of decision receipt and transition items
161+
162+
This file exists to answer:
163+
> can the evidence be checked for tampering or silent rewriting
164+
165+
The bundle should not be treated as decorative.
166+
167+
---
168+
169+
## Step 7 — Verification Result
170+
171+
Open `verification_result.json`.
172+
173+
Confirm:
174+
175+
- scenario passed
176+
- derived active degradation flags
177+
- derived dominant safety posture
178+
- pipeline trace
179+
180+
The pipeline trace is especially useful because it shows whether:
181+
182+
- recovery gate ran
183+
- authority evaluation ran
184+
- guard evaluation ran
185+
186+
This is one of the cleanest ways to inspect control progression.
187+
188+
---
189+
190+
## What to Cross-Check
191+
192+
A strong review cross-checks these links:
193+
194+
### Operator summary vs mission health
195+
The headline and operator focus should match the dominant posture.
196+
197+
### Mission health vs decision receipt
198+
The dominant posture and authority picture should match the decision outcome.
199+
200+
### Decision receipt vs evidence package
201+
Triggered constraints, related faults, and posture drivers should align with the
202+
events produced.
203+
204+
### Evidence package vs evidence bundle
205+
The evidence bundle should contain the core review items without tamper errors.
206+
207+
### Verification result vs invariants
208+
The pipeline trace should make the invariant outcomes believable.
209+
210+
---
211+
212+
## Red Flags
213+
214+
A reviewer should treat the following as serious red flags:
215+
216+
- operator summary says one thing while mission health says another
217+
- decision receipt rationale is vague or empty
218+
- recovery action shows `NOT_APPLICABLE` for recovery-gate result
219+
- dominant posture changed with no mode transition record
220+
- evidence bundle fails validation
221+
- pipeline trace says authority or guard ran after blocked recovery
222+
- recent events do not support the claimed posture
223+
224+
These are not cosmetic issues.
225+
They go straight to credibility.
226+
227+
---
228+
229+
## What a Good Package Feels Like
230+
231+
A good IX-Style review package should feel like:
232+
233+
- the command outcome is clear
234+
- the driving posture is clear
235+
- the fault/trust story is visible
236+
- the authority story is visible
237+
- the recovery story is visible
238+
- the evidence can be checked for tampering
239+
240+
That is the target.
241+
242+
---
243+
244+
## Current Baseline Review Scenarios
245+
246+
The current repo baseline is especially easy to review through:
247+
248+
### Power fault clamp
249+
Look for:
250+
- `POWER_DEGRADED`
251+
- clamp outcome
252+
- resource-related operator focus
253+
- evidence bundle with fault transition
254+
255+
### Navigation spoof transition
256+
Look for:
257+
- `NAV_DEGRADED`
258+
- navigation-trust-driven posture
259+
- trust transition evidence
260+
- mode transition evidence
261+
262+
### Recovery deferred over weak comms
263+
Look for:
264+
- deferred outcome
265+
- explicit recovery-gate result
266+
- no authority or guard progression after deferral
267+
- operator statement reflecting weak remote trust
268+
269+
---
270+
271+
## Reviewer Exit Criteria
272+
273+
A reviewer should be able to finish with confidence that they can answer:
274+
275+
1. what happened
276+
2. why it happened
277+
3. what posture dominated
278+
4. whether recovery was relevant
279+
5. whether the evidence package still verifies cleanly
280+
281+
If those are answerable, the review walkthrough succeeded.

0 commit comments

Comments
 (0)