Stage 3: reconciliation

Stage 3 adds duplicate reports, delays, denials, contradictions, and incorrect locations. Reconciliation converts reports into the current set of incident beliefs.

The design

Reconciliation is deterministic code. It is not a model call.

flowchart LR
    T["human text"] --> I["LLM intake"] --> R["reports: evidence"] --> C["code reconciliation"] --> B["incidents: beliefs"]

The intake model records what a caller said. Reconciliation uses fixed spatial, time, and incident-type rules. The same input and state must always give the same result.

The supplied policy uses these main cases:

Truck vision is more reliable than a human report:

• A normal building closes the matching incident.
• A burning building confirms or opens an incident.

What is provided

The instructor provides the complete reconciliation policy and implementation. Use the Stage 3 reference solution or the files supplied in class.

The solution includes:

• report matching by distance and time;
• incident confidence and contradiction fields;
• merge rules;
• truck-vision rules; and
• the REC-* scenarios.

What Claude implements

Claude does not design a new solution. Claude integrates the supplied solution into your repository.

Claude changes only these parts:

1. Claude applies the supplied changes to reconcile.py.
2. Claude adds the supplied incident fields.
3. Claude connects reconciliation in runner._process_tick.
4. Claude resolves merge conflicts with your Stage 1 and Stage 2 code.
5. Claude runs all REC-* scenarios.

What you decide and check

You do not choose a new reconciliation policy in this stage. You must understand the supplied policy.

Ask Claude to trace:

• two reports that refer to the same fire;
• a denial near an open incident; and
• truck vision that contradicts a report.

For each case, identify:

• the matching rule;
• the outcome;
• the store method that records the change; and
• the evidence that remains in the report store.

What you do not build

Do not add:

• an LLM call for matching;
• embeddings or a vector database;
• a new store;
• new matching rules; or
• Stage 4 dispatch changes.

Prompt Claude

Paste this prompt into Claude Code. Give Claude access to the supplied solution files.

Integrate the supplied Stage 3 reconciliation solution.

Read reconcile.py, both stores, runner._process_tick, features/reconcile.feature, and the supplied solution. Do not design a different reconciliation system.

Before you edit, trace these cases through the supplied design:

• Two reports refer to the same fire.
• A denial is near an open incident.
• Truck vision contradicts a report.

For each case, name the matching rule, outcome, and store mutation.

Then integrate only the supplied changes:

• Apply report-to-incident matching in reconcile.py.
• Add the supplied confidence and contradiction fields.
• Apply the supplied truck-vision rules.
• Connect reconciliation in runner._process_tick.
• Resolve conflicts with my Stage 1 and Stage 2 code without changing their behaviour.

Keep reports as append-only evidence. Keep incidents as mutable beliefs. Do not add a model call, embeddings, a vector store, or another persistence layer.

Run uv run behave features/reconcile.feature. For one scenario, show the sequence of outcomes and store mutations.

At the end, explain which intake errors reconciliation can correct and which errors it cannot correct.

Check the result

Run:

uv run behave features/reconcile.feature
uv run hadr-runner stage3-partial@londone

Inspect the outcomes from one episode.

• Many OPEN outcomes can mean that matching failed.
• One incident with many unrelated reports can mean that matching is too broad.

Use the reconciliation review prompt to check for hidden model calls or policy in the wrong layer.

Completion criteria

• The supplied solution is integrated.
• All REC-* scenarios pass.
• Reports remain separate from incident beliefs.
• You can explain why reconciliation is deterministic code.