LandfallDocs
Architecture

Shared context

Every war room has one shared context: the set of findings and decisions every investigator, and every investigator's agent, is expected to work from. What a responder's harness shares does not enter it on say-so: a finding waits until the room admits 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 what is staged, how an item gets in, how it gets out, who is told, and where all of that is visible.

How it works

Proposed
by a person or their harness
→
Waiting
a bar per kind of item
→
In the shared context
every agent works from it
→
Removed
challenged and voted out, with a reason
→
Restored
by a person, with a reason
Side door
an admin admits a waiting item, with a reason
Side door
autonomous mode: agents admit a plain observation
→
In the shared context
the history says how it got in
The life of one item. Every step is an event on the incident timeline, so the Context tab, every agent's brief and the post-incident record read the same history.

Two kinds of thing can be in the shared 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 proposes or a responder's harness shares. It enters once it meets a corroboration bar that scales with how much damage a wrong one could do: an observation needs one other voice 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, and in an incident room an observation that verification succeeds on is admitted automatically. It stays contestable.
  • 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.

People decide

What is staged. A finding or hypothesis a responder's harness shares through the landfall CLI, and a finding a person proposes with + Propose. A note a harness shares is a plain feed item and is not staged. Beacon's own findings and hypotheses go to the room directly; they are not staged.

On a finding, the people in the room vote and flag. On a default install a harness casts no vote: the CLI's bridge gives it no vote or flag verb, and Beacon casts none either. The engine counts an agent's corroboration as one distinct voice only where an agent can cast one, such as the CLI's fallback direct surface (see the CLI reference). In an incident room a plain observation is admitted automatically once Landfall has re-checked it against the source.

Whoever votes, people carry the weight: anything above a plain observation needs a human in the chain (the author or a corroborator), a claim that contradicts admitted context needs an organization member, and a human override always wins. When a human has switched autonomous mode on for a room, enough agents agreeing can admit a plain observation on their own; root-cause claims and suggested actions always need a human. On a proposal (a decision the room takes), only humans vote. The API lets an agent session attach a signal (its position, its confidence, and which artifacts it examined) that is shown to the room as evidence and is never counted toward the majority; no landfall CLI tool sends one today. 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.

Two rules keep that honest. Posting a finding is your vote for it, whether you posted it by hand or your agent did: the tally starts at “1 for” and the card lists you as “posted it”. That vote can never admit the finding on its own, so a second vote of yours is refused with that explanation and its buttons are disabled, and so is a vote from your own agent on a finding you posted by hand; every bar still needs someone other than the author, or an agent acting for someone other than the author, to agree. And when an organization's admins may admit an item directly (Settings → Governance, on by default and audited when changed), an admin can enter a waiting item with a reason; the item's history and the post-incident record then read “admitted by <admin>: <reason>” rather than a bar that was met. This is how a room with one human member gets anything into the shared context without lowering its bars.

The admission gate and its modes

The gate is enforcing for every organization by default: the findings a harness shares or a person proposes wait in the Context tab 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 and every claim enters at once, but the Context tab still shows each item's bar as advisory, so an organization can judge the friction before enforcing.
  • Off: every claim enters immediately and its history says the gate was off.

The same Governance section holds Admins may admit items directly and the retraction delivery mode described below. 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.

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 shared 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”.

The roster, which opens from the agents pill at the top of the Context tab, marks every joined member as current, behind (with how long ago their last pull was), or as having no agent or companion bound, and lists each agent with its channel and last pull. 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 shared context can be challenged. Challenge asks why it is wrong (a reason is required) and starts a removal vote; the item stays in context until enough people agree, and a member can vote Keep instead. The person who posted a finding can retract it at once. Any member can also mark a finding invalid now, which removes it on their word with their reason on record. 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 person, with a reason, 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 post-incident record

The record's Shared context section is built from the same timeline fold as the Context tab, 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.

The record's headline follows the same rule. A hypothesis becomes the root cause only when the claim proposing it was admitted to the shared context and not later removed; the executive summary is drawn from that hypothesis alone. Hypotheses that never entered, including ones an agent shared, are listed under “Considered, not admitted” with the reason they did not enter: what the claim was still missing, that it was removed, or that nobody ever proposed it. When nothing entered, the record says plainly that no root cause was established. Entry reasons and proposal bars in the record are computed with the organization's actual gate mode and the room's actual joined-human count, so they match the live Context tab.

Where you see it: the Context tab

Every incident has a Context tab beside Canvas, Postmortem, Comms and Status. The tab itself carries the number of findings waiting for your vote and a dot when something entered, left or is newly waiting since you last opened it. The tab opens inside the same war room, with the same header and the same chat beside it, so switching from the canvas is a content swap rather than a change of screen.

From top to bottom, the Context tab shows:

  • One header line: how many items are in context, waiting and removed, when it last changed (times are in UTC), a pill saying how many members' agents are up to date, and + Propose to stage a finding of your own. The pill opens the roster described under Pulls.
  • A notice in words when an administrator has set the gate to report-only or off, the autonomous-mode banner when that mode is on, and a line saying what changed since you last looked.
  • The items that need your vote, gathered in one strip above everything else.
  • Filter chips with counts: All, In context, Waiting and Removed.
  • The ledger: one row per item, oldest first, placed at the time it was proposed. A row shows the time, a mark and a word for its state, the statement, and its vote trail from the proposer to the voters to the outcome. The incident's own declaration and each stage are dividers, pinned chat messages and withdrawals are thin lines, and a quiet stretch of ten minutes or more is marked. Items that need you start open.
  • An open row shows the full statement; its kind, class, stated confidence and level; its whole story (how it entered, each vote with its reason, agent evidence labelled as not counted, verifications, and for a removed item who challenged it, who voted it out and whether it was restored); and the controls that apply. A waiting finding takes Relevant or Not relevant, a waiting proposal Support or Oppose; an item in context takes Challenge; a removed one takes Restore.
  • For an admin only, a closed Governance settings section at the bottom, where autonomous mode is turned on for this room, with an optional reason, or off.

When something is waiting on you, the incident header says so in one chip that takes you straight here. The organization-wide rules (the gate mode, whether admins may admit directly, and how retractions are delivered) are under Settings → Governance, described in The admission gate and its modes.

What an agent sees

An agent joined to the room (through the landfall CLI, the Edge companion, or a hosted connector) receives the shared 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 that has the vote verbs (the CLI's fallback direct surface has them) can corroborate or contest a finding from there, and its corroboration is a counted vote. No agent can vote on a proposal, and on a default install a harness has no vote verb at all. Staged findings that have not entered are absent from every other agent's context, and so is everything people say about them (votes, reasons, flags and the platform's own checks) until they enter. A removed item leaves agent context the moment the quarantine lands, and what was said in its favor leaves with it. That holds for vote requests too: an agent is asked to vote only on findings it can already read, and a teammate's finding that is still waiting for a person's vote reaches it as a count at most, never as its words. An agent is never asked to vote on a finding its own person posted: that finding needs a vote from someone else.

Autonomous mode is the one exception. While a person has switched it on, every agent in the room is shown the plain observations waiting for a vote, in its awaiting decision section and its vote requests, because enough agents agreeing on one is how it enters without a person. Nothing above an observation is shown this way, the timeline still holds the observation back until it enters, and turning the mode off hides them again.

What a harness shares follows the same rule. A finding a responder's harness posts into the room is proposed to the shared context as an observation, and a hypothesis as a causal claim, attributed to the agent acting for its investigator; the agent's stated confidence travels with it as a signal. Members see the share in the chat with a “waiting for the room” badge and vote on it from the Context tab; other agents receive it only once the room admits it, or, for an observation, while autonomous mode is on as a finding waiting for their vote. A note is the exception: it stays a plain feed item that everyone sees at once, and it never enters the shared context. Beacon's own findings and hypotheses are not proposed this way: they are posted to the room directly, and every joined agent reads them as room events.

Why it is built this way

Everything above is a projection over the incident timeline: votes, verifications, pulls and removals are events, and the Context tab, 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 in agreement, and lets a room be replayed as a deterministic test. Read alongside the Company second brain, which learns only from findings that earned their way into a shared context.

What is not here yet

Nothing is listed here. Every part of this page has shipped.