A guided look at how we build — 2 · The screen path: six stops

The path takes an intent, which is a sentence about something you want true, and turns it into a built, tracked initiative. You start and finish in a conversation. In between, you read three pages.

① builder session ──► ② briefing draft ──► ③ workbench ──► ④ lane activity ──► ⑤ initiative report ──► ⑥ builder session
   say it               read it back           place it         watch it build       judge it              change it

1 · Open the builder session and state the intent

What you do. Open a Claude session that has the map tools, and say what you want in your own words. The session sends back a proposal: where the work sits in the tree, its branches, and a done-test for each branch. You review the proposal for width. Does it fit somewhere in the world you already track? Does it connect to work that already exists, or does it duplicate it? Clarify until the proposal says what you meant. Then describe the briefing you want: what it should report and how often it should update. When it matches, accept it.

What you see. A chat that answers with a short tree (initiative → numbered branches), one criterion per branch with a REACH-TEST: clause, and the parent it will sit under. Once you accept, the nodes exist on the map, and your words are quoted as a ruling on the root.

What decides it. Your accept. Nothing is created until you agree to the tree. Your words go on the node verbatim, and the session's summary of them does not replace them.

Served today by: a Claude Code Remote Control session on Rob's own account. Today that is rob-switchboard, opened from claude.ai/code or the phone app (remote-sessions rc <name> starts another one). The session runs the /InitiativeProcess skill (decompose → agree → children with criteria). Check: remote-sessions list showed rob-switchboard live, last used 3 minutes before the check. This initiative was itself chartered in that session (f0639b05) on 2026-10-08.

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• https://claude.ai/code — State an intent (builder session) · input · owner · menu: Builder session, owner /app account sheet (AppAccountNav) — in the menu today · opens a Claude Code Remote Control session with the map tools (today: rob-switchboard)

Gap. Rob's design (10:47 CT) is a guest's default session with the right tools, so any user can start the path without a dedicated box. No default-session preset exists yet. Listed on pua-7-gaps.

2 · Read the briefing draft

What you do. Open the briefing that the new initiative will publish, and check whether it reads as a report on your intent. It should not read as a report on the machinery.

What you see. A briefing page with six parts in order. The intent comes first, in your words. Then a one-line verdict, the evidence for it, what changed, what needs you, and the detail.

What decides it. Whether the first two lines would tell a stranger what you want and how far along it is. If they don't, go back to stop ① and say so.

Served today by: https://analyst-server.com/briefings/rob/files/projects/post-using-analyst-server.md (the initiative's briefing). Check: 200, briefing article rendered.

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• /briefings/<group>/<slug>.md — Briefing draft for an intent · output · owner · menu: Briefings, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out

Gap. There is no per-intent briefing section yet: a section keyed to the intent node and generated in the six-part order above. Today each briefing file is written for its initiative. The work to close this is upgrade proposal up-c32822f8 (filed 2026-10-08 on skill-cascade-intent-loop). Listed on pua-7-gaps.

3 · Place it on the workbench

What you do. Open the workbench rooted at the new initiative's parent. Check how the new node fits beside its parent and siblings. Check that it isn't a duplicate, that it hangs under the right parent, and that its criteria don't overlap a sibling's. Then assign it a work lane, which is the stream its build activity is filed under.

What you see. The tree explorer: the parent, the new initiative, its numbered branches, and each branch's criteria with met or unmet status.

What decides it. Placement: right parent, no twin among the siblings. The lane decides where progress shows up at stop ④.

Served today by: https://analyst-server.com/briefings/rob/workbench?root=big-init-post-using-analyst-server (or ?root=big-init-nature-products to see the siblings). Check: 200, and the rendered page carries pua-2-screen-path and pua-7-gaps.

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• /workbench?root=<slug> — Workbench (place it; edit an intent) · both · owner · menu: Workbench, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out

Gap. The workbench has no lane control. Today the lane is assigned in the builder session: the --lane on activity-log entries and the box's roster purpose. Listed on pua-7-gaps.

4 · Watch the lane's activity

What you do. While the engine and boxes build the branches, open the activity for this initiative's lane and watch the build move.

What you see. A newest-first stream for the lane: map steps (criteria landing, rulings, new nodes), worklog entries from the boxes, and milestones. You can filter it to a single lane with the lane chip.

What decides it. Movement. If the lane has gone quiet while criteria are still open, ask why. That usually means a parked card that is waiting on you, or an engine that isn't aimed at this branch.

Served today by: https://analyst-server.com/briefings/rob/activity (the live stream, with lane filter). Check: 200. Also https://analyst-server.com/briefings/rob/files/pai-work/lanes.md (the activity journal grouped by lane, regenerated on a schedule). Check: 200, briefing article rendered.

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• /activity — Activity (live stream, lane filter) · output · owner · menu: Activity, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out
• /briefings/engine/grinder-lanes.md — Lane activity briefing · output · owner · menu: Grinder lanes, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out

Gap. At the check, pai-work/lanes.md had no row yet for the post-using-analyst-server lane, because the lane's first journal entries are only now being written. Nothing is missing in the code, so this is not listed on pua-7. The row appears when the page next regenerates.

5 · Read the initiative briefing report: is the intent fulfilled?

What you do. Open the initiative's briefing again, this time as a judge. Read the verdict and the evidence, and ask one question: does this page show my intent fulfilled?

What you see. The same page as stop ②, now filled in. A verdict line with a count of criteria met, an evidence table by branch, what changed, and what needs you.

What decides it. Your yes or no. "All criteria met" is the machine's claim. Your reading of the report is the decision. If the report is true but doesn't answer the intent, the intent or its criteria were wrong, and that sends you to stop ⑥.

Served today by: https://analyst-server.com/briefings/rob/files/projects/post-using-analyst-server.md. Check: 200, briefing article rendered. It currently reads "Started — chartered today… 0 of 10 criteria met".

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• /briefings/<group>/<slug>.md — Initiative briefing report · output · owner · menu: Briefings, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out

Gap. Same as stop ②. The verdict is on the initiative, not on each intent, until up-c32822f8 lands.

6 · Back to the builder session: request changes

What you do. Return to the session you started in and say what is wrong or missing, in plain words. The session files your ask verbatim as an upgrade proposal. The next upgrade turns it into an agreed change to the tree and its criteria, and you agree to that change the same way you accepted at stop ①.

What you see. Your words come back as a proposal against the initiative. Once you agree, the new or amended branches and criteria appear on the workbench, and the loop runs again from stop ③.

What decides it. Your agreement to the changed tree, exactly as at stop ①.

Served today by: the same Claude Code Remote Control session type as stop ① (rob-switchboard, live at the check). Asks are filed with ops/walk/upgrade-proposal.mjs file --initiative <slug> --words "…". For example, up-c32822f8 was filed this way on 2026-10-08.

Route & menu (generated from web-apps/as-web/src/lib/route-map.mjs by ops/posts/gen-screen-path.mjs; edit the map, not this block)

• /past-topics — Past topics (pick a topic back up) · both · owner · menu: Past topics, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out
• /proposals — Upgrade proposals · both · owner · menu: Proposals, owner /app account sheet (AppAccountNav) — in the menu today · expects 200 signed in, 307 to sign-in when signed out
• https://claude.ai/code — Request changes (builder session) · input · owner · menu: Builder session, owner /app account sheet (AppAccountNav) — in the menu today · opens the same builder session as stop 1; asks filed with ops/walk/upgrade-proposal.mjs

Gap. Same as stop ①. There is no default guest session with these tools yet. Listed on pua-7-gaps.

Probe record (2026-10-08)

Gaps sent to pua-7-gaps: default guest builder session (① ⑥) · per-intent briefing section up-c32822f8 (② ⑤) · lane control on the workbench (③).

Route map — every input and output screen

Generated from the same map as the stop blocks above. A route marked ✗ has no menu item yet; closing that is pua-10-owner-menu-complete and pua-10-guest-menu.

A guided look at how we build — 3 · Five variations: one path, five kinds of work

Every initiative on the map is filed under one of five kinds, called natures. The nature is set at stop ①, when you accept the proposal and it is placed under a parent. From then on it decides what the criteria test for and what the briefing has to show you.

① Ventures & Prospects — a bet on the world

Done means: Pipeline stage explicit · worked recently or consciously parked · a qualify/decision artifact exists.

The usual reason to go to stop ⑥ is that the world moved. A prospect said no, or the price changed. You restate the bet, or you park it.

② Products — a surface for other people

Done means: Shipped and reachable · in actual use · value stated.

The usual reason to go to stop ⑥ is that a user did something you did not expect. You change the surface or the value statement.

③ Apparatus-build — extending the machine

Done means: Capability deployed not just designed · proven by a test · build gates enumerated.

On the map, apparatus initiatives sit one level down, inside containers such as Capabilities. The usual reason to go to stop ⑥ is that a gate turned out to be the wrong test.

④ Posture & Lenses — staying ready

Done means: A standard defined · reviewed on a cadence · current status vs standard known.

The usual reason to go to stop ⑥ is that you learned something new, such as a new threat or a new failure. You raise the standard and the next review checks against it.

⑤ Research — understanding first

Done means: Question stated · a finding exists · the finding is linked to the initiative it feeds.

The usual reason to go to stop ⑥ is that the answer changed the question. You restate it, or you close the research and move the work to the initiative it fed.

What stays the same

All five kinds go through the same six stops. Every criterion carries a REACH-TEST: clause that says what must be true and how to check it. The machine claims "met" only after an independent check passes. At stop ⑤ the decision is still yours: the briefing shows whether the intent was fulfilled, and you are the one who says yes.

A guided look at how we build — 4 · Side posts

How-to templates — copy one

Each template walks the same six stops as part 2: ① state the intent, ② read the briefing draft, ③ place it on the workbench and give it a lane, ④ watch the lane, ⑤ judge the report, ⑥ request changes. For its case, each one fills in the intent text, the tree, the lane and the briefing.

More use cases are added here as they come up (Rob 2026-10-08: "and other specific use cases").

Walkthroughs — played, not read

Each one is a script for the one beat player (player/index.html); open it with ?script=<topic>. Build walkthroughs walk the six stops on a real initiative; reference tours step screen by screen. Schema: scripts/beat-script.schema.json.

Why it's needed — one per piece

Each of these explains why the piece is necessary, not how it works inside. They are listed here when they are written.

• The grinder — not written yet
• Local LLM capacity — not written yet
• Scheduled triggers — not written yet
• The choreography engine — not written yet
• Recoverability — not written yet
• The security model — not written yet
• How a guest's allowed-sites list grows — safely — why web reads ask, and the four-step loop that adds a site only with the owner's yes

A guided look at how we build — 5 · The worked example: security, through all six stops

The security initiative existed well before 2026-10-07. Its four branches were all machinery: coverage proof, monitoring, the CASA posture groups, and the threat register. They overlapped, and none of them answered the question a person actually asks, which is where is the danger? This walk-through is the morning that changed.

① say it ──► ② read it back ──► ③ place it ──► ④ watch it build ──► ⑤ judge it ──► ⑥ change it
  09:32–09:42   ten-class table   ten branches +   lane "security"     9 of 10 red      the next ask
  10-07         as top layer      Operations       73 entries          on 10-08         is already written

① The builder session: the question, the proposal, the accept

Rob opened his builder session (rob-switchboard) and asked a question. He did not give an instruction. These are his words, verbatim, on 2026-10-07:

09:32 CT — "I am trying to get a picture of what our potential vulnerabilities are. if you could classify all vulns into 10 or less categories, what would those classes be?"

The session proposed ten classes, each in plain words. That proposal is the table in stop ②. Rob then checked it for width: should this shape stay on a report, or should it be the shape of the work itself?

09:40 CT — "I do want top layer of security briefing to look like this, but I also want the initiatve to look like this too. would it be possible and reasonable to organize initiative big-init-security like this, perhaps with an operations root that would contain things like the Threat Register?"

That one message did two jobs of stop ①. It described the briefing (the top layer becomes the class table), and it placed the work (the initiative takes the same shape, with the existing machinery moving under an Operations branch). The session's recommendation was to break up the four CASA goal groups (reachable, access, integrity, scrutiny) into the classes, and to keep CASA only as a report lens under Operations. Rob accepted:

09:42 CT — "run that and REC CASA as suggested"

What landed on the map: criterion sec-root-ten-classes-plus-ops on big-init-security (status today: met), plus two follow-on criteria on Operations: sec-ops-briefing-top-layer-is-classes and sec-ops-casa-groups-refiled (both met as of 2026-10-08).

② The briefing draft: does it read as the intent?

The intent was "give me a picture of our vulnerabilities". The test at stop ② is whether the top of the briefing reads as that picture, not as a list of machines. The draft that came back is the ten classes, each in words a stranger could follow:

Underneath the classes sit the seven promises they protect: keep strangers out · everyone's data stays theirs · never act against me · nothing changes without my knowing · don't lose it, keep running · don't run away with my money · tell me the truth.

Where it lives: the security briefing, whose first table is now "The ten classes of risk": Security briefing — the ten-class table.

③ The workbench: fit with parent and siblings, and a lane

On the workbench the reshape is a tree. The axis changed from which machine watches to where the risk is:

big-init-security — Security: ten classes of risk, and the machinery that watches
├── sec-c01-front-door              1 · Front door              perimeter · websites · remote access
├── sec-c02-stolen-keys             2 · Stolen keys             credential theft
├── sec-c03-too-much-power          3 · Too much power          identity · overreliance
├── sec-c04-thin-walls              4 · Thin walls              segmentation + container privilege
├── sec-c05-data-walking-out        5 · Data walking out        egress
├── sec-c06-poisoned-parts          6 · Poisoned parts          endpoints/images · repo hygiene
├── sec-c07-hidden-changes          7 · Hidden changes          host integrity · service roster
├── sec-c08-ai-turned-against-you   8 · AI turned against you   prompt-injection · LLM carrying controls · engine claims
├── sec-c09-loss-and-runaway-cost   9 · Loss & runaway cost     recovery · liveness · spend + throughput
├── sec-c10-blindness              10 · Blindness               forensics + disclosure + governance · alarm rungs
└── sec-ops-operations              ⚙ Operations
    ├── big-init-coverage-proof          (coverage proof)
    ├── big-init-security-monitoring     (monitoring + the alert sentinel)
    ├── secmon-llm-risks                 (the threat register)
    └── big-init-security-posture        (CASA, kept as a report lens)

Each of the 20 posture checks maps to exactly one class. Each class was born with one criterion: all of its posture checks read PASS.

The fit checks at this stop:

• No twins. The old branches did not get a sibling copy. They moved under Operations with their slugs unchanged, so lanes, owners and alert-fix nodes that name them still resolve. Only the parents moved.
• Open work follows the risk. The 37 unmet CASA criteria moved verbatim to the class whose harm each one prevents. For example, rate-limit and spend went to class 9, and roster, authority and sudo went to class 3. Met history stayed on the old groups under Operations.
• The lane. Build activity is filed under the lane security.

Where it lives: https://analyst-server.com/briefings/rob/workbench?root=big-init-security (owner screen; the public post shows a screenshot, pua-6).

④ Lane activity: watch it build

Once the tree was accepted, the engine and the boxes built the classes. Each class criterion (its checks all read PASS) became work, and the work was filed against the lane.

What the screen showed on 2026-10-08: the lanes page (/briefings/rob/files/pai-work/lanes.md) lists security with 73 entries, latest Oct 8, 6:26 AM CT. Contributors include the engine cycles, the alert grinder, and builders on sec-c09-… and sec-ops-…. The reshape session's own entries are filed under big-init-security (3 entries, rob-switchboard, latest Oct 7, 1:23 PM CT).

The stream also shows what a builder declined to do, with a reason, and it is worth reading at this stop. One example from class 7: "Did not auto-roster new _schedules at birth … that touches the scheduler create path shared with guests." A builder's restraint is a decision you can overturn in one line.

⑤ The initiative briefing report: is the intent fulfilled?

Back to the briefing, this time as a judge. The intent was a picture of where we are vulnerable. On the morning of 2026-10-08, the top of the security briefing read:

From the Security briefing's ten-class table, verdicts from the check bundle of Oct 8, 2026, 4:00 AM CT. Each class is as bad as its worst check. On the live page each class name opens its branch, and each check name opens that check.

Is the intent fulfilled? For the question that was asked, yes. Nine of ten classes are red, and you can see which nine at a glance, in plain words, with each one a single click from the work that would turn it green. That is the picture that was asked for. It is not a good picture, but a briefing is meant to be true, not reassuring. The structural criteria are met, and the class criteria (all checks PASS) are the open work.

⑥ Back to the builder session: request changes

Reading the report at stop ⑤ raises the next ask, and the machine has already written it down. When sec-ops-briefing-top-layer-is-classes closed on 2026-10-07, its close gate recorded a need that no criterion had asked for:

"The INDEX now says 8 of 10 classes are red, but the one page Rob reads each morning (daily.md) still speaks in sentinel alerts and layers, not classes — the new top layer is a page he must go and open …"

A day later a second finding sharpened it: with most classes standing red, a class that turns red overnight adds one name to a long red list and is not called out on its own.

At stop ⑥ that becomes a sentence in the builder session, something like "tell me when a class goes red, on the page I read every morning". It is filed verbatim as an upgrade proposal against big-init-security. The loop then runs again from stop ③. The tree doesn't change shape; it gains a criterion on Operations.

Probe record (2026-10-08 ~11:25 CT)