FCC for Coordination Stewards¶
Welcome to the FCC tutorial track designed for coordination stewards — the practitioners who maintain the cross-repo coordination records that anchor FCC to its three ecosystem authorities (NEXUS, PHOENIX, ORCHESTRA). If your job is to ensure that an artifact moving from FCC toward the ecosystem publishes cleanly across every authority boundary, this track is for you.
A coordination steward is not a build engineer, not a release manager, not a compliance officer. The role is adjacent to all three and unique unto itself: it owns the living documents that encode cross-repo contracts, maintains the cadence at which those documents are reconciled against live state, and shepherds new authorities through the shared format template when a fourth, fifth, or sixth lane eventually lands.
Why this track exists¶
Prior to FCC v1.7.1 the coordination surface was scattered across two version-tagged files (rc-coordination-v143.md, ice-ext-patent-coordination-v143.md) and a set of undocumented conventions that lived in agent memory. v1.7.1 restructured the surface into a dedicated subdirectory, adopted a unified format template, and made the records first-class citizens of the docs/ecosystem/ tree. That restructure also promoted a new organizational function into visibility: someone has to maintain the coordination records themselves — reconciling them against drift, shepherding new authorities, and teaching others how to read and write them.
This track is the onboarding path for that someone.
What you will learn¶
By the end of this track you will be able to:
- Read any of the three tri-authority coordination records (NEXUS, PHOENIX, ORCHESTRA) and summarise its current state for a non-technical stakeholder in under two minutes.
- Identify which of the six shared-template H2 sections is most likely to drift between releases, and know the mitigation pattern for each.
- Shepherd a new authority through the shared format template end-to-end, from first proposal to merged record.
- Walk the three lane-specific handoff flows (research paper, open-science validation, cross-repo contract test) with confidence — including the owner-approval and counsel-gated preconditions.
- Update the landing
README.mdand thetri-authority-topology.mddiagram when a fourth authority is codified.
How this track is organized¶
| Page | Focus | Reading time |
|---|---|---|
| Getting Started | First read of the coordination subdir; mental model | 20 min |
| Reading Coordination Records | Section-by-section reading guide for all three records | 30 min |
| Writing New Coordination Records | Shared format template + new-authority onboarding checklist | 35 min |
| NEXUS Handoff Flow | Research/JV paper handoff walkthrough | 25 min |
| PHOENIX Open-Science Flow | Open-science validation walkthrough | 30 min |
| ORCHESTRA Contract-Test Flow | Cross-repo contract-test authoring walkthrough | 30 min |
Total reading budget: ~3 hours if you go straight through. Most stewards revisit pages as reference over the course of several weeks.
Prerequisites¶
- Comfortable reading Markdown with YAML front matter.
- Comfortable reading a GitHub PR description and a CI workflow file.
- Familiarity with the difference between an owner-approval gate (the human decision that something is ready to cross a boundary) and a counsel-ack gate (a legal or IP-licensing acknowledgement).
- Light familiarity with the FCC persona catalog is helpful but not required — the coordination records cite specific personas (RHL, IHL, OSC, PCT, LAR, OTO, EDM) and we explain each in context.
If you have ever owned a cross-team runbook, maintained a CODEOWNERS file, or stewarded an ADR registry, you have all the analytical skills this track needs.
The three authorities at a glance¶
Before diving in, internalise the one-line summary of each authority:
| Authority | Codename | Lane | FCC-side owner personas |
|---|---|---|---|
| Research & Joint Ventures | NEXUS | Academic papers, JV convening, registry source-of-truth | RHL |
| Open-Science | PHOENIX | Open-science validation, patent/IP consolidation, 58-gate registry | IHL, OSC, PCT |
| Integration-Tests | ORCHESTRA | Cross-repo contract-test validation across 5 partner repos | LAR, OTO |
Each authority has its own cadence, its own confidentiality posture, and its own set of owner-approval gates. The coordination records are the single place where all three are reconciled into a readable surface.
What a coordination steward is not¶
- Not a patent attorney. PHOENIX lane work is counsel-gated; the steward owns the record, not the IP strategy.
- Not a release manager. Releases cross authority boundaries; the steward records the crossing, but the release manager owns the release.
- Not a test engineer. ORCHESTRA contracts are authored by the personas that own the surfaces being tested; the steward records the contract, not the code.
Think of the coordination steward as the archivist + editor-in-chief of the cross-repo coordination surface.
Where to go next¶
If you are reading the records for the first time, start with Getting Started. If you have already skimmed all three records and want a structural reading framework, jump to Reading Coordination Records. If a fourth authority is imminent and you need to shepherd its first record into the subdirectory, go directly to Writing New Coordination Records.
Cross-reference: docs/ecosystem/coordination/README.md is the canonical landing page; this tutorial track is the pedagogical companion to it.