Evidence, Not Claims: Building the FDE Companion OS

Two FDEs apply for the same senior role. Same years of experience; same caliber of customers. The first sends a polished resume and a portfolio site with five case studies — hero images, clean "client" / "challenge" / "approach" / "results" blocks: "Architected a scalable, production-ready AI assistant that transformed customer support operations and unlocked significant ROI."

The gap is not skill — both can do the work. The gap is in what evidence each has accumulated, in a shape a senior reviewer can interrogate. Marketing is auditable on the surface only; evidence is auditable all the way down. By the end of this lesson you will have set up your own Companion OS, populated all seven slots for one prior engagement, and filed at least one piece of evidence that a skeptical senior FDE would accept.

By the end of this lesson, you will be able to:

The §7 lab produces a populated repo for one of your real prior engagements. The model in §4 is the lens. The §6 evidence-vs-marketing rewriter is the forcing function that prevents portfolio-style filling. Create is the load-bearing outcome — the act of producing real evidence, not describing it.

Today's lesson is the operating-system layer beneath everything in 1.4 through 1.6. The Trinity, the Maturation Loop, the Lifecycle, founder-like ownership, and the Narrow Path are all useless across engagements unless their outputs accumulate somewhere a future you can audit. The Companion OS is that somewhere. The §7 narrow-path diagram you wrote in Lesson 1.6 is slot #3 of your first engagement.

Why "operating system," not portfolio or wiki

The Companion OS is named operating system on purpose. It is not a portfolio site (its audience is your future self before it is any hiring panel). It is not a wiki (its shape is fixed, not free-form). It is not a knowledge base (it stores evidence about your engagements, not facts about the world). The closest popular analog is Tiago Forte's PARA method (Projects, Areas, Resources, Archives), which organizes information by actionability. The Companion OS borrows PARA's discipline of organizing by usage but swaps the dimension: instead of actionability, the organizing dimension is lifecycle stage and evidence type. That swap is the entire point.

The seven slots — click to explore

Each engagement gets a folder. Inside, exactly seven slots, exhaustive across the lifecycle and non-overlapping. Click any slot in the file tree on the left to see its contents and fullness criterion.

What closes the loop between Prototype and Adopt

Of the seven slots, four sit clearly inside a single lifecycle stage and three operate as bridges. The most important bridge — and this lesson's spaced-review answer — is slot 4, the eval. The eval is the artifact that lets a Prototype cross into Adopt without the rung-3 stall Lesson 1.4 named. Without an eval, "shipping" stays "shipping" and the Day-2 owner is never confident enough to take ownership. The eval is the contract under which Adopt happens.

Cross-engagement layer (Patterns)

Below the seven slots in each engagement folder, the Companion OS holds two cross-engagement folders. patterns/ collects observations that hold across multiple engagements — phrasings that worked in a defense, eval techniques that surfaced a class of failures, demo formats that landed with skeptical operators. templates/ holds the blank versions of slots 1–7 so each new engagement starts in 30 seconds, not 30 minutes. Both are PARA-style "Resources" in Forte's vocabulary; they sit above engagements in your repo and are the place reused FDE judgment lives.

Tool agnostic. The same seven slots can live in a private GitHub repo, a Notion workspace, an Obsidian vault, or a folder on your laptop. Tool choice is personal preference; the slot structure is the contract.

The senior FDE's Polaris Companion folder, exactly as it sits in her repo today (twelve weeks after the §1.6 narrow-path conversation with Janet). For each slot: the actual compressed contents, and the one filing decision that distinguishes the entry from a portfolio version of the same thing.

Three sentences from real portfolio sites of working FDEs. Each is marketing language. Rewrite each as evidence — a statement that a skeptical senior FDE could verify or falsify in two minutes. Your rewrite must (a) name a specific number or artifact, (b) be locatable (link, file, or commit), and (c) survive the "so what?" test. Live checks run as you type.

Scaffold drop. Notice that evidence rewrites are typically twice as long as the marketing originals. That is the cost of evidence — and the reason most portfolios stay marketing. The §7 lab will ask for the same discipline on your own slots.

Brief

Pick one prior engagement of yours — finished or current. Use the populator below to draft all seven slots. The populator persists locally; you can come back to it. Mark each slot Full or Placeholder honestly. At the end, export as Markdown and drop into your repo of choice (GitHub, Notion, Obsidian, or a plain folder).

Acceptance criteria (peer-checked)

• All seven slot files exist, named per the §4 convention.
• At least three slots pass the evidence-vs-marketing standard from §6.
• The slot 7 retro names you (the FDE) by behavior — not the customer by mistake.
• The README (auto-generated on export) explicitly labels placeholders as placeholders.
• A peer reviewer can open any slot and explain back what is in it within 30 seconds.

Honesty clause: On most prior engagements, slots 4, 5, and 6 will be partially or entirely empty. That is expected and is itself useful information — it is the signal that prompts the next engagement to file differently. The lab is not graded on how full your repo is; it is graded on how honestly the slots reflect the engagement's actual evidence.

Look at the seven-slot Companion you just built. Answer honestly.

The Companion OS is the single Course 1 artifact that compounds across engagements. Trinity, Maturation, Lifecycle, Ownership, Narrow Path — all are taught once. The Companion OS is the substrate in which those frames accumulate evidence and improve over a career. This reflection is your first deposit.

Success criterion: The eval (slot 4). It is the contract under which Adopt happens — the artifact a Day-2 owner needs to take ownership and the document a customer's security and operations teams need to put the system in front of real users.