Cairn Documentation
Lenses 12
Each lens is a different engineering view of the selected node, grouped in the lens bar as Model, Story and Analysis. Press a lens's letter, or a digit for the first nine, to switch. Overview is the hub: a card for every other lens says what is behind it.
Model
The hub for the selected node. Its name and description edit in place. Budgets roll up from the children, and a card for every lens says what is behind it (requirements traced, verification coverage, states, brief sections out of date). A suggested next step is the first gap Completeness finds that AI can help close; on a system built from the interview, a From your interview card comes first instead, with a first proposal still waiting for review and the steps the interview points to, until you are done with it. Below: children with their health, then previews of requirements, interfaces, visuals and attachments.
What the node must do, as a list or a flowdown outline that nests derived requirements under their parents across levels. Each row shows the statement, type, priority, the nodes that satisfy it and its verification methods by status. Gap chips find untraced, unverified, failing and badly worded requirements (no "shall", several "shall"s, unverifiable words, performance without a number). A requirement is traced when a trace link that has not been rejected touches it. Keyboard: arrows, Enter, /.
The node's children as blocks and every interface between them at any depth: direct connections, connections through their parts (dashed), and links to nodes outside its boundary, with arrows for signal flow. Also an N² chart and the interface list with signals. A node with no parts is shown in its context.
The node's state machine three ways: a diagram laid out by steps from the initial state, with a step-through simulator; the transition table; and a state × event matrix showing which events each state ignores. Flags unreachable states, dead ends, final states with exits and transitions that compete for one event. Add states and transitions by hand or with AI.
A verification cross-reference matrix: one row per requirement, a column each for Inspection, Analysis, Demonstration and Test, and the requirement's state. Click an empty cell to add that method. Activities lists every verification by status, failing first, with status set in place. Closure counts requirements: passed when all their activities passed, failing when any failed or is blocked.
How the node is used: its use cases, each with actors, what holds before and after, its steps, and the requirements traced to it. Actors link by name to the external actors of the node and the nodes above it; a name nothing matches is flagged and can be added to the model. Every list is edited in the inspector, and use cases can be added by hand.
Story
The node in 8 sections of prose (purpose, capabilities, operating modes, architecture, interfaces, constraints, verification, risks), each written from named parts of the model and citing the entities it draws on. A section says when the model has moved on since it was written, and what changed; AI updates just those sections through Change Review. Text you write locks its section.
How the node's parts work together, as a systemigram (Boardman): its children and the links their interfaces make, drawn before any AI runs; AI picks the mainstay and a verb for each link and writes the story, through Change Review. Says when the node, its parts or the links have moved on. Offered for nodes with children.
Concept images in style kits (render, technical, artistic, schematic), each recording the part of the model it was drawn from and marked out of date when that changes, plus a 3D model built with MeshBuilder and Three.js that a new one replaces only once it is built.
Analysis
What is missing from the node, as checks along Pace/Loper fidelity axes (what it is, what it does, how it connects, how we know), each read from what another lens shows and leading to the lens that fixes it. Checks that do not apply are left out. The tree shows each node’s gaps while the lens is open.
Pyramid of Causality (Harney): the capstone over its domain technologies, components and parts, with the interfaces and requirements beneath. Each stone has a maturity stage, and the capstone can be no further along than the least mature stone it rests on: the lens names the limit and what sets it. Maturity is set by hand or assessed by AI through Change Review.
The decisions behind a design: for each node with parts, what was chosen, the alternatives set aside (what each was weighed against, why it lost, its first principle, decision type and phase) and what is still open, and which decisions record no alternative. Edited by hand in the inspector. Offered for nodes with children.