Skip to content

Ecosystem Coordination — Tri-Authority Records

FCC's cross-repo coordination is organized around three authorities, each owning a distinct lane of the ecosystem. This subdirectory collects the canonical coordination records for all three. Every sibling record follows a shared format template so an external reader, a new persona, or a future authority can read them in parallel and quickly compare cadence, handoff artifacts, cross-repo contracts, and open items.

The three authorities

Authority Codename Lane Coordination record
Research & Joint Ventures NEXUS academic papers, empirical methodology, JV convening, registry source-of-truth nexus-research-coordination.md
Open-Science PHOENIX open-science validation, patent/IP consolidation, 58-gate quality registry phoenix-open-science-coordination.md
Integration-Tests ORCHESTRA cross-repo contract validation across 5 partner repos (+1 optional) orchestra-integration-tests-coordination.md

The three authorities are intentionally orthogonal: an artifact moving from FCC toward the ecosystem may touch all three (e.g., a new persona that underwrites a paper, has a patentable algorithm, and adds a plugin entry-point), but each authority applies its own contract independently. A change only publishes once all three have acknowledged.

For the topology and visual cross-reference of how FCC, the three authorities, and the ten constellation projects relate, see docs/ecosystem/tri-authority-topology.md (Agent C).

Why this subdirectory exists

Prior to v1.7.1 FCC carried two single-record files at the docs/ecosystem/ top level: rc-coordination-v143.md (NEXUS scope) and ice-ext-patent-coordination-v143.md (PHOENIX scope, but patent-only). Those records were version-tagged (-v143) and narrowly scoped, and a third authority (ORCHESTRA) had no dedicated record despite owning the ecosystem's public contract-test surface.

v1.7.1 restructures by:

  1. Creating this coordination/ subdirectory as the single anchoring location for cross-repo coordination records
  2. Migrating the two existing files via git mv (preserving full commit history)
  3. Rewriting the NEXUS record to frame its full Research & Joint Ventures authority scope (not only the two industry papers)
  4. Expanding the PHOENIX record from patent-only to the full Open-Science authority umbrella (open-science validation + patent/IP consolidation + 58-gate quality registry)
  5. Adding the new ORCHESTRA record for the Integration-Tests authority
  6. Adopting a unified format template so all three read in parallel
  7. Dropping the -v143 version suffix from filenames (each record now carries version in its front-matter and is updated in place)

Shared format template

Every record in this subdirectory conforms to the following skeleton. When a fourth authority is eventually codified, author its record from this template.

---
title: <Authority> Coordination Record
authority: <NEXUS | PHOENIX | ORCHESTRA | ...>
scope: <1-line description>
version: v1.7.1
last_updated: YYYY-MM-DD
---

# <Authority> — <Role> Coordination Record

## Authority role

<2-3 paragraphs: what this authority does in the ecosystem, why FCC depends on it, what role it plays in cross-institutional work>

## Coordination cadence

<How often this authority and FCC sync; per-PR / per-PI / per-release / weekly / ad-hoc; specific PI targets if any>

## Handoff artifacts

<What FCC hands to this authority; what this authority hands back. Include confidentiality tier if any.>

## Cross-repo contracts

<Which FCC modules / APIs / files this authority touches or validates. Table form preferred.>

## Open items

<Owner-approval-gated or counsel-gated items tracked here. Items should name the blocking persona + the unblocking precondition.>

## References

<Sibling records, topology diagrams, procedural contracts, claim matrices, CI workflows, persona YAML sources, relevant ADRs.>

How to use these records

  • As an FCC contributor: before proposing a change that crosses an authority boundary, read the relevant record and confirm the change matches an existing handoff pattern. If not, open a coordination-record amendment alongside your change.
  • As a partner-repo maintainer: these records are the authoritative statement of what FCC expects from your repo and what you can expect back. If your upcoming change breaks an expectation, flag it against the relevant authority first.
  • As an external reviewer or auditor: the three records together are a complete map of FCC's cross-repo coordination surface. Combined with docs/ecosystem/alignment-status.md (current state) and docs/ecosystem/tri-authority-topology.md (diagrammatic view), they replace the need to trace across multiple internal docs.
  • As a future authority author: when a fourth lane is codified, use the template above and add a row to the table at the top of this page. Update docs/ecosystem/tri-authority-topology.md to reflect the quad-authority shape.

Cross-references

  • Tri-authority topology diagram: docs/ecosystem/tri-authority-topology.md
  • Ecosystem alignment status (live state): docs/ecosystem/alignment-status.md
  • Codename decoder (authoritative codename ↔ repo map): docs/ecosystem/codename-decoder.md
  • Universal services (shared cross-authority services): docs/ecosystem/universal-services.md
  • Ecosystem README: docs/ecosystem/README.md
  • Patent delegation runbook (procedural contract for PHOENIX lane): docs/governance/patent-delegation-runbook.md
  • Patent claim matrix (cross-authority IP state): docs/governance/patent-claim-matrix.md
  • Architecture decision records: docs/decisions/ (five ADRs relevant to coordination patterns)