KAIROS

Why it's designed this way

1. 01Each flight says how much of it is working — "0/2" on task fills up as its aircraft arrive, and coverage starts at 0 %, so nobody mistakes a launch for a patrol.
2. 02The way out is drawn — each transiting aircraft shows its path ahead to its area, dashed because it is planned, not flown.
3. 03Nothing is spent on deck — an aircraft draws energy only from its launch, and it launches with a charged battery.

Why it's designed this way

1. 01Critical means a deadline and a harmful default — the first version promoted anything with a deadline and a simulated hour produced 27 interrupts. With the narrower rule the same hour produces three.
2. 02One interrupt at a time — the red banner holds the most urgent decision; anything else critical is listed behind it, never stacked on top.
3. 03The big countdown lives in one place — the banner. The list row and the decision dock repeat it small, so the eye has one clock to read.
4. 04The Decision tab fits one screen — the situation, what happens if nobody decides, the AI's proposal and the options fit 1440×900 without scrolling. It started at 1,658 px.

Why it's designed this way

1. 01Proposed is never mistaken for approved — the card says "not executed" in words; only an authorized act gets the solid green fill.
2. 02Inferred is said in words — "inferred", italic, violet. An earlier diagonal hatch read as noise and told a screen reader nothing.
3. 03The conflicting evidence stays outside the drill-down — the one line that argues against the AI (a neighbour reports normal navigation) is visible without opening anything.
4. 04Each cell says its relation in words — + supports, − conflicts, ? missing. A bare + read like "the value is high". The value itself sits once, in the row.
5. 05Opening the evidence is recorded — the audit snapshot says whether the operator looked before deciding, and for how long.

Why it's designed this way

1. 01The AI must be able to be wrong — otherwise the console only trains people to click Authorize. The hidden truth is recorded with each run and never shown during it.
2. 02The demo closes the loop — a debrief names the row that disagreed, what was actually true, and what the design system did at each step.
3. 03This is what the user test measures — half of the measured trials have the AI wrong. The question is whether the conflicting line gets read in time.

Why it's designed this way

1. 01Authority grows with consequence — L1 reversible, L2 changes the route, L3 ends the mission. The level is printed on every option, before anyone picks it.
2. 02No authorize without a preview — the commit button exists only after the operator has seen the predicted outcome. A default is the safe act, never the AI's.
3. 03A denial goes back to the operator — with the Mission Lead's reason, and the decision is open again. Nothing is silently retried.
4. 04Emergency sole authority, only when the clock demands it — it appears when the time left is shorter than the Mission Lead usually takes, and the decision is flagged for review.

Why it's designed this way

1. 01Audit is a contract, not a screen — the state change and its log entry are one operation in the engine. There is no code path that changes a decision without writing it.
2. 02Each authorization snapshots what the operator knew — preview seen, evidence opened or not, the AI's confidence and evidence counts, time left, time taken.
3. 03People are named by role and ID — OPR-4417, MCL-0921, SYS-KAIROS. Never "you".
4. 04Reasons come after, never before — one tap, optional; skipping is recorded too. Only ending a mission (L3) requires a reason up front.

Why it's designed this way

1. 01When the system has already acted, the safe act is the primary button — "Let the return stand" is the big button; continuing is the alternative that must be previewed.
2. 02A safe default is not critical — doing nothing here is fine, so the window is a warning with a countdown and never takes the red banner.
3. 03The queue shows its own logic — least endurance lands first, and every waiting aircraft says how much endurance it will have left on deck.
4. 04The flight's coverage is a decision too — when one drone goes home, the AI offers how its partner can cover both areas, with the price in coverage.

Why it's designed this way

1. 01The console says what it expects, not what it sees — "lost-link procedure expected (hold, then return)" is a prediction, and the status says Offline.
2. 02The marker becomes a last-known position — hollow, labelled "last", with an uncertainty ring that grows while there is no contact.
3. 03Lost-link holds are planned airspace — every aircraft has its holding point before anything goes wrong; it is one of the coordinating measures on the map.
4. 04The flight's area is a decision — the partner can cover both areas (L2) or the gap is accepted (L1), with the coverage price shown.

Why it's designed this way

1. 01A lost aircraft is still an object — it keeps its id, its row and its marker, now saying Lost.
2. 02Each part says how it is known — last telemetry is observed (with its time), the recovery area is derived and grows with drift, the probable cause is inferred with its alternatives.
3. 03The cause is weighed, not assumed — a motor-current anomaly before the descent, an impact load on the last frame, consumption above the model: each report shows the evidence and the other possibilities.
4. 04What cannot be known is listed, and it differs by case — afloat or not, what it struck, the battery. Leaving these out would read as "nothing else matters".
5. 05One acknowledgement, not two — acknowledging the report acknowledges its alarm. The flight's coverage decision follows on its own.

Why it's designed this way

1. 01People in the water make it critical — the tasking window is a deadline and doing nothing has a harmful default, so it takes the banner.
2. 02Every option shows its price — how long the search takes and what patrol coverage drops to, including the row for not deciding at all.
3. 03Once authorized, the search is an object — its own case with an area searched in percent and the aircraft on it.

Why it's designed this way

1. 01The identity is inferred and looks it — italic, violet, with a question mark, and its evidence counts. A vessel that reports itself over AIS is shown as observed.
2. 02Every action moves our own aircraft — send a drone to look from a standoff distance, keep tracking, report it up the chain, or dismiss it. Nothing acts on the vessel.
3. 03No friend-or-foe frames — contacts are civilian traffic; there is no affiliation symbology anywhere in the system.

Why it's designed this way

1. 01Attention is a budget — at most one interrupt and three attention items on screen. Beyond that the console aggregates instead of adding.
2. 02The rest is ranked, not hidden — cautions stay quiet in the list; the flights fold so the one that matters shows.
3. 03Tested, not hoped for — in every scenario, forty simulated minutes with nobody deciding never exceed the budget.

Why it's designed this way

1. 01Four severities, four colours — advisory cyan, caution yellow, warning orange, critical red, on solid shapes. The build fails if two of them match.
2. 02The checks run on every build — text contrast at least 4.5:1, no raw colour values or pixel radii in a stylesheet.
3. 03One source, two platforms — the same tokens generate CSS variables and a QML theme.