The main context

Every war room has one main context: the set of findings and decisions every investigator, and every investigator's agent, is expected to work from. Nothing enters it on say-so. A finding waits until other people corroborate it, a proposal waits for a majority of the humans in the room, and anything that later turns out to be wrong is voted back out with a reason on the record. This page describes how an item gets in, how it gets out, who is told, and where all of that is visible.

One list, two kinds of item

Two kinds of thing can be in the main context, and the room shows them in one list so there is exactly one place to look:

• Findings. An observation, correlation, causal claim or directive that a person or an agent stages. It enters once it meets a corroboration bar that scales with how much damage a wrong one could do: an observation needs one other person to agree, a causal claim needs two and at least one must be an organization member. A platform verification (Landfall re-running the query behind the finding) can stand in for a corroborator on an observation.
• Proposals. A statement that a resource is or is not implicated, typically opened by an agent. It is decided by a strict majority of the humans currently in the room, so three joined investigators need two votes. There is no timeout and no override: a proposal that never reaches a majority simply stays open.

Humans decide, agents supply evidence

An agent can stage a finding, open a proposal and attach a signal: its position, its confidence, and which artifacts it examined. A signal is shown to the room as evidence and is never counted toward a bar or a majority. Only a human vote changes what is in the main context, and a person has one live vote per item: voting again replaces the earlier vote rather than adding to it, whether the vote came from the room, the Edge panel or a bridged chat workspace.

Two numbers travel with a finding and are deliberately kept apart. The stated confidence is what the proposer or its agent claimed, on a 0 to 1 scale. The level (unsupported, asserted, corroborated, reproduced) is what the room has actually established, derived from who corroborated and whether the platform could reproduce it. The level is an explanation, not a score, and nothing in Landfall averages the two.

Where it is visible: the main-context widget

The war room's canvas mounts a protected widget at the top: it is present on every member's canvas from the moment the room opens, and no prompt, agent or drag can remove, hide or reorder it. It shows, without a click:

• A status line: how many items are in the main context, how many are waiting, how many were removed, and when it last changed. If an administrator has set the admission gate to report-only or off, the status line says so in words.
• An investigation timeline strip: when the incident was declared, each lifecycle stage, and every point at which the main context changed. Selecting a point opens that item's history.
• The waiting list, ordered by how close each item is to a decision: proposer, kind, stated confidence, level, the bar it must meet, the tally, everyone who has taken a position with their reason, and the agent evidence. Vote controls sit on the row and adapt to the kind.
• In context, Removed and Not admitted sections, each with a per-item history: when it entered, why (the bar it met, the majority that accepted it, an administrator's override, or that it was grandfathered from before the gate was switched on), each voter with their reason, each platform verification, and, for a removed item, who flagged it, who voted it out and why, and whether it was restored.
• A pull roster: which team members' agents are working from the current main context (see below).

Pulls: who is working from the current picture

A shared context only helps if the people investigating actually have it. Landfall records a pull whenever an investigator's agent session or Edge companion receives a main context that changed since its last recorded pull. The record names the member, the channel (agent session or Edge companion), the time, and which items were included. A member reading the room in the browser is deliberately not a pull: the roster answers "is this person's harness working from the shared picture", not "did they look".

Each item shows who pulled it since it entered, one entry per member with their latest pull. The roster marks every joined member as current, behind (with how long ago their last pull was), or no agent bound. Pull records are visible to the room and to the post-incident record; they are bookkeeping and are never fed to an agent as context.

Voting an item out, and telling the agents that had it

An item already in the main context can be flagged, then voted out. A vote to remove requires a reason; the room keeps the entry trail and the removal trail side by side, so a reader sees how it got in and how it got out. A removed item can be restored by a human, and the restoration is appended to the same history.

Because agents may already be acting on a retracted item, every agent session that had pulled it is told, with the removal trail attached. How loudly is an organization setting (Settings → Governance):

• Urgency routing (the default): interrupt the investigator whose held line or own contribution depends on the item; everyone else who pulled it hears on their next turn.
• Always interrupt: every agent that pulled it is interrupted, still bounded by the per-participant interrupt budget.
• Next interaction only: no interruptions; agents learn of it the next time they read the room.

The admission gate and its modes

The gate is enforcing for every organization by default: contributed findings wait in the widget until they earn admission. Items that were in a room before the gate was switched on are grandfathered in and labeled as such in their history; nothing disappears when the gate turns on. An administrator can change the mode under Settings → Governance:

• Enforcing: findings and proposals wait until admitted.
• Report-only: nothing is held; the widget shows what the gate would have held, so an organization can judge the friction before enforcing.
• Off: every claim enters immediately and its history says "the gate was off".

Every change of the gate mode or the retraction delivery mode is written to the organization's audit trail with the value before and after.

What an agent sees

An agent joined to the room (through the landfall CLI, the Edge companion, or a hosted connector) receives the main context as established fact, and a separate awaiting decision section that lists what is still waiting, with its bar and tally and the literal label "not established". An agent can corroborate a finding or attach a signal to a proposal from there; it cannot vote. Staged findings that have not entered are absent from every other agent's context, and a removed item leaves agent context the moment the quarantine lands.

The post-incident record

The record's Main context section is built from the same timeline fold as the live widget, so the two never disagree: for each item, how it entered and who voted, who pulled it, and, if it was removed, who removed it and why. Withdrawn items appear as a count only, never as content. The same redaction pass that protects the rest of the record applies to vote reasons.

Why it is built this way

Everything above is a projection over the incident timeline: votes, verifications, pulls and removals are events, and the widget, the agent brief and the record are three readers of one fold. That is what makes the history reconstructible days later, keeps the live view and the record byte-for-byte in agreement, and lets a room be replayed as a deterministic test. Read alongside the Grandbo memory architecture, which draws only on findings that earned their way into a main context.