Skip to content

NEXUS Handoff Flow — Research Paper Walkthrough

This page walks through a concrete NEXUS handoff end to end: FCC seeds a paper in docs/papers/, RHL holds the weekly sync, NEXUS extends the paper with methodology and results, author-order is negotiated, and the post-publication SHA anchors into the mirror tree. By the end you will have a mental timeline of a full PI window and know which steward-owned steps happen along it.

The two reference papers

FCC has two papers queued in v1.7.1:

Paper FCC source Target venue (preferred) PI target
Quantum-Locality docs/papers/quantum-locality/ ACM SIGMOD / IEEE Quantum Week / ICML QAI Workshop RC PI-2026-Q3
Zachman-R.I.S.C.E.A.R.+SAFe docs/papers/zachman-riscear-safe/ IEEE Software / ACM SEN / XP-Agile 2026 RC PI-2026-Q4

Either makes a good walkthrough; we use Quantum-Locality below because it is also adjacent to an invention disclosure (FCC-INV-002 Dual-Bus Architecture) and so exercises the RHL ↔ IHL peer coordination loop.

Actors in this flow

  • RHL (Research Handoff Liaison) — FCC-side owner of the research lane. Archetype The Ambassador.
  • IHL (Innovation Handoff Liaison) — FCC-side owner of the patent lane. Coordinates with RHL when a paper is adjacent to an invention disclosure. Archetype The Bridge Diplomat.
  • GCA (Governance Council Arbiter) — called into joint RHL/IHL sync when a paper's defensive-publication posture needs explicit governance sign-off.
  • NEXUS counterparts — upstream research-center authors who extend FCC seed artifacts with methodology, simulation, and empirical results.
  • Coordination steward — you. You own the coordination record itself. You do not author the paper, but you verify that its handoff state is captured correctly.

Stage 1 — Seed artifact preparation (FCC side)

Before the PI window opens, RHL assembles the seed artifact bundle in docs/papers/quantum-locality/:

  • abstract.md — 150–250 words
  • outline.md — H1 / H2 / H3 headings with 1–3 sentence section abstracts
  • citations.bib or citations.md — minimum 20 references
  • figures/ — architectural evidence (UML, ADR references, code-path citations)
  • manifests/ — reproducibility manifest (datasheet + model card + evidence graph)

Steward check: the record's Cross-repo contracts table cites docs/papers/quantum-locality/. Verify the path exists in the tree. If it does not, the record is wrong and the seed artifact has been renamed or moved.

Stage 2 — Weekly sync cadence

RHL holds a weekly sync with NEXUS counterparts across active PI windows. Cadence is documented in the NEXUS record's Coordination cadence section.

Steward touchpoints in Stage 2:

  • Verify the record's last_updated front-matter field reflects the most recent structural change (not every sync requires a bump; content-only syncs do not bump the record).
  • Cross-check the record's PI-window list against what RHL actually shipped in the last PI. If the record says RC PI-2026-Q3 — Quantum-Locality paper but no seed has been shipped, flag it to RHL.

Stage 3 — Peer coordination with IHL (patent-adjacent papers only)

Quantum-Locality is adjacent to FCC-INV-002. This triggers the RHL ↔ IHL joint-sync protocol:

  1. RHL flags the adjacency in the weekly sync record and pings IHL.
  2. IHL reviews the Patent Claim Matrix (docs/governance/patent-claim-matrix.md) for FCC-INV-002's Counsel Status and PHOENIX Mirror Status.
  3. If the provisional filing decision is still open, the paper preprint timing is held until the decision is made (or until counsel explicitly clears defensive-publication).
  4. GCA is called in if governance sign-off on the defensive-publication posture is needed.
  5. RHL and IHL agree on a sequence, document it in both the NEXUS record (paper side) and the PHOENIX record (patent side), and RHL proceeds.

Steward check: the NEXUS record's Peer coordination with IHL section should name the specific invention (FCC-INV-002 Dual-Bus Architecture) and cross-reference the PHOENIX record. If either of those references is stale, the coordination is undocumented.

Stage 4 — NEXUS extension

Once the RHL/IHL sequencing is green, NEXUS extends the seed. The handoff-back artifacts (from the NEXUS record's Handoff artifacts section) are:

  • Experimental methodology section draft
  • Results section (empirical data, statistical analysis)
  • Venue-specific formatting + submission coordination output
  • Author-order negotiation record

Author-order defaults are typically alphabetical within-institution, FCC first-authored for FCC-originated contributions. Any deviation is documented in the author-order negotiation record, which is attached to the paper's manifests/ subdir.

Steward check: the record states "FCC first-authored for FCC-originated contributions". If RHL and NEXUS reach a different agreement for a specific paper, the record should reflect it as an exception. Do not let exceptions accumulate without a note.

Stage 5 — Submission + publication

NEXUS submits the paper to the target venue. Once accepted, the post-publication state is anchored:

  • A SHA-anchored entry at <nexus-repo>/docs/papers/<name>-fcc-handoff/ is created.
  • FCC's weekly patent-mirror-check.yml sibling (paper-handoff variant, v1.4.4+) verifies backlink integrity between FCC's seed at docs/papers/<name>/ and the NEXUS-side entry.
  • The NEXUS record's Queued handoffs section is updated: the paper moves from "queued" to "published" with the publication citation and SHA.

Steward check: the Queued handoffs section is one of the most drift-prone parts of the NEXUS record. After every published paper, confirm:

  • The paper is removed from the queued list (or marked as published).
  • The publication citation is added to the record's References section.
  • The drift-CI log (weekly patent-mirror-check.yml sibling) shows green for the mirror entry.

Stage 6 — Registry-mirror side (always-on)

Separately from the paper lane, NEXUS owns the port-allocation + ecosystem-projects registries. FCC vendors them at:

  • src/fcc/data/ecosystem/port_allocation.yaml
  • src/fcc/data/ecosystem/ecosystem_projects.yaml

The CI test at tests/test_ecosystem_registry_drift.py pins the vendored copies by SHA256 and drift-checks against the NEXUS source when that repo is checked out locally.

Steward check: after any FCC release that bumps the vendored registry SHAs, verify the NEXUS record's Cross-repo contracts table still cites the drift-test path correctly. If the test is renamed or moved (unlikely but possible), update the record.

Stage 7 — Record refresh

Every FCC release is a chance to refresh the NEXUS record. The steward's release checklist:

  1. Bump last_updated in the front matter if anything changed.
  2. Verify Coordination cadence is still accurate (especially the weekly / per-PI tiers).
  3. Scan Queued handoffs — did anything publish, get rejected, or pivot to a different venue?
  4. Scan Open items — close resolved items, add release-tag to any that were opened this release.
  5. Verify every path in Cross-repo contracts resolves against the FCC tree.
  6. Verify References cross-links are current.

A clean NEXUS-record refresh is typically ten to twenty minutes of steward work per FCC release.

A worked timeline

Date Stage Actor Steward action
Q2 2026 1 — seed ready RHL verify path + manifest completeness
Q2 2026 2 — weekly sync opens RHL ↔ NEXUS confirm PI-window listed in record
Q2 2026 3 — IHL coord (if patent-adjacent) RHL ↔ IHL ↔ GCA cross-check both records
Q3 2026 4 — NEXUS extends NEXUS no steward action; watch for hand-back artifacts
Q3 2026 late 5 — submission NEXUS no steward action
Q4 2026 (or later) post-publication anchor NEXUS + RHL move paper from queued → published; add citation
per-release 7 — record refresh steward checklist above

Common failure modes

  • Seed artifact renamed without record update. Path in Cross-repo contracts goes stale silently. Mitigation: scripted path-existence check on release.
  • Paper pivots to a different venue. Record's PI-window list names an obsolete venue. Mitigation: update on every PI-window boundary.
  • RHL/IHL coordination done by email. The joint sync happened, but the record does not reflect it. Mitigation: steward asks RHL at every weekly to confirm all patent-adjacent papers are captured.
  • Registry SHA drift. FCC releases bumped the vendored SHAs but the drift CI log was not re-read. Mitigation: steward reads the CI log as part of the release refresh checklist.

Where next

For the other two authorities, see PHOENIX Open-Science Flow and ORCHESTRA Contract-Test Flow. To deepen your sectional reading, revisit Reading Coordination Records.