Lesson 66.1 gave you the map: one idea, one canonical asset, purposeful derivatives. This lesson gives that map a workshop to live in. Because maps drawn on whiteboards die; maps kept in files, boards, and approval gates survive contact with a busy week.

Calendars don't make quality. Systems do.

Every struggling creator has had the same experience: the calendar says "publish Tuesday," Tuesday arrives, and there is nothing worth publishing. So something thin goes out, the audience notices, and trust leaks a little. The mistake was treating the calendar as the engine. A calendar tells the team *when* something should be ready. It cannot turn a weak, unsupported idea into publishable work.

An editorial operating system does the unglamorous work underneath the calendar: ideas are captured before they vanish, research is stored where the drafter can find it, briefs prevent each asset from inventing its own message, reviews catch errors before the audience does, and learnings carry into the next round. Boring? Yes. That is the point. Quality that depends on heroics is not a system.

The seven files that hold the operation

You already know the tools from earlier in the course. Part II taught you that Markdown preserves direction across sessions and collaborators. Part X taught you that task and decision files prevent invisible work. This lesson applies both to content. Seven durable files, all plain text, all findable without opening a chat window:

Keep the layers separate on purpose. Ideas are cheap and plentiful; research is slow and precious; briefs are decisions; assets are outputs. When these collapse into one chat thread or one person's memory, the operation develops amnesia: drafts cite facts nobody stored, assets get reused past their rights window, and nobody remembers why a series was killed. Files remember so people don't have to.

Part VIII connects here too: agents can assist bounded steps inside this system — gathering sources, drafting variants, formatting metadata — but only because the files define the bounds. An agent without a brief invents; an agent with a brief accelerates. Lesson 66.3 draws that boundary in full.

The two-week board: eight statuses, one owner per gate

A board is a promise about movement. Use eight statuses and move every active item through them in roughly two weeks:

research → brief → draft → review → approved → scheduled → published → learn

• Research: evidence is being gathered. Exit needs a source log, not a vibe.
• Brief: the editor has decided audience, promise, proof, and shape. Exit needs a written brief.
• Draft: the asset exists in rough form. Exit needs a complete draft, not fragments.
• Review: factual, brand, and accessibility checks run. Exit needs named sign-offs.
• Approved: the asset is locked. Further changes need a new review pass.
• Scheduled: publish time, channel, caption, and metadata are set.
• Published: the asset is live and archived with its record.
• Learn: response is logged and the next brief is updated. Without this step the board is a treadmill.

The load-bearing rule: one accountable owner per approval gate. Research can be collaborative; approval cannot. Name the human who signs the brief, the human who signs factual review, and the human who signs publication. "The team reviewed it" means nobody did. When a claim turns out wrong or a brand line gets crossed, the log should show whose gate it passed — not to assign blame, but so the gate gets fixed.

Scope the board ruthlessly. A two-week board holds what two weeks can actually carry: for a small operation, three to five active items. Everything else waits in IDEAS.md without guilt. Overloading the board is how research gets skipped and review becomes a rubber stamp.

Exercise: stand up your board

Create a PRODUCTION-BOARD.md for the next two weeks. Seed it with at least three real items at different stages — one in research, one in draft, one awaiting review — so the board reflects reality instead of aspiration.

# Production Board — [dates]

## research | owner:
- [idea] — evidence needed:

## brief | owner:
- [idea] — audience / promise / proof:

## draft | owner:
- ...

## review | fact owner: / brand owner:
- ...

## approved / scheduled / published / learn
- ...

Include the approval owners by name at the top. If you are a solo creator, write your own name three times — the point is that each gate is a distinct decision, even when one person makes all three. Future you, or an agent assisting you, needs to see which hat was worn when.

Done means: seven files exist (or folders with stubs), the board shows three items in different statuses, and every gate names an owner. Verify: pick any item and trace it backward — can you find its brief, its research, and its reviewer without asking anyone? Common failure: a board where everything sits in "draft" with no owner and no exit criteria. That is a wish list, not an operating system; split it into the eight statuses and assign the gates.

Check your understanding

• Why does a calendar fail as a quality mechanism, and what replaces it?
• What is the difference between IDEAS.md, a brief, and an asset — and why must they live in separate files?
• Why does each approval gate need exactly one named owner?

In the next lesson you will connect agents to this system — what they may gather, draft, and schedule, and where they must stop and hand control to a human.