X-1 orphan reuse audit — The Rail

Audit date: 2026-07-22

Source requirement: §10 of V_SERIES_AMBIENT_RAIL.md and X-1 of the implementation ledger

Decision summary#

The three flagged assets have now been traced to their actual source and evaluated against every plausible Rail component:

The Aphrodite game-bridge family is six private, process-local game simulation packages. None is a production adapter to the named external domain, and none is adopted by the Rail.
Calliope Stage is adopted as V3 Stage's normative concert-design contract. That adoption is already implemented at the durable cook-candidate boundary; Calliope is not treated as a renderer or playable-media source.
Concordia's real homes are the canonical contract package, mediation orchestrator, and Oshun workbench integration. It is a separate cooperative mediation product rather than a Rail substrate, so it is not adopted.

This is intentionally not a package-name matching exercise. Reuse is accepted only when the existing asset owns the same authority and can preserve the Rail's truth, consent, absence, and provenance invariants.

1. Aphrodite game-bridge adapters#

Family-level finding#

The phrase libs/aphrodite/* game-bridge adapters resolves to exactly these six packages:

They are substantial, typed, well-tested local engines, but “bridge” does not mean they call their namesake product. Their production sources have no import from any external domain package. State is held in in-memory maps and module-local counters; time comes directly from Date.now(), and several features use local seeded or unseeded random generation. They expose no durable repository, authenticated service client, consent/provenance receipt, or media artifact boundary. Their completeness is therefore completeness as Aphrodite game simulations, not as cross-domain production integrations.

Package	What the code actually owns	Plausible Rail overlap	Reuse verdict
Hathor game bridge	In-memory world templates, NPC personalities, narrative arcs, quests, dialogue, and lore consistency	RD.2's V5 newspaper, Mind Palace, or world windows	Do not adopt. RD.2 requires projections from the V5 world's actual persisted simulation history. Generating a parallel game world would fabricate the events the newspaper must report.
Isis game bridge	Local level/dialogue/NPC/difficulty/music/SFX/background generators returning descriptors	Case content, Stage media, or automatic direction	Do not adopt. It has no model/provider execution, rendered bytes, immutable delivery, or provenance evidence. Treating its generated descriptors as content would violate the Rail's no-fabricated-content rule.
Lilith game bridge	Meditation “power,” biometric ability modifiers, consciousness realms, and a breathwork minigame	X-4 Tara presence or RA.7 Motion	Do not adopt. It is an Aphrodite game mechanic with caller-supplied biometrics, power/reward semantics, and random realm discovery. Tara must use Tara's real breath pacing, and Motion already owns the humane, evidence-bound guided-act path.
Maya bridge	Asset import, ECS mapping, renderer, physics, and network simulations	RD.1 My Realm / Realm Surf	Do not adopt. This is an Aphrodite game-runtime bridge, not Maya Crucible or the Mawu economy. It even synthesizes output sizes; it cannot evidence an economy delta, realm state, rendered asset, or network session.
Nike game bridge	Exercise-rep mapping, heart-rate difficulty, calorie rewards, and fitness challenges	RA.7 Motion or future mobile micro-acts	Do not adopt. Its calorie rewards, loot, difficulty multipliers, and caller-supplied sensor readings conflict with the Rail's no-guilt/no-punishment posture and do not supply Motion's authoritative program or completion evidence.
Nyx game bridge	Caller-populated star maps and orreries, in-memory astronomical schedules, game triggers, constellation effects, and performer effects	X-4 Nyx sky-and-awe	Do not adopt. The canonical `@nyx/ephemeris` and `@nyx/sky-clock` already own observer-aware ephemerides, visibility, location consent, and tonight-only materialisation. Importing the Aphrodite game model would add a weaker second astronomy contract and could turn caller-authored events into apparent sky truth.

Because every member is rejected for Rail reuse, this family creates no X-1 implementation follow-up. The packages remain valid Aphrodite-owned game code; the verdict is about Rail authority, not package quality.

2. Calliope Stage specification#

Source and authority#

@calliope/stage exports the typed concert concept, setlist, stage, screen, venue, camera, VFX, audience, streaming-plan, and VOD-plan schemas plus 30 deterministic design services. Its cross-object refinements bind artist, concept, setlist, stage, venue, camera, VFX, and audience identities. Its streaming layer describes protocols, quality profiles, perspectives, chat surfaces, and package plans; it does not produce encoded bytes, a delivery URI, a manifest, a checksum, or a playback observation.

Reuse verdict: adopt as a contract, never as media evidence#

The adoption follow-up is already implemented by RA.8:

RA8_V3_STAGE_CHANNEL_INTEGRATION.md records Calliope as the normative Stage specification and keeps V3's tenant, rights, authoring, export, and provenance authority separate.
candidate-source.ts imports the canonical ConcertSetlistSchema, VirtualCameraSystemSchema, and StreamingIntegrationLayerSchema from @calliope/stage/contracts rather than copying them.
The durable candidate projection requires exact identities across the V3 and Calliope objects before the cook can read a candidate.
The cook still requires separately rendered bytes, immutable storage, exact delivery verification, and a playable catalog record. A Calliope plan alone cannot become a Rail item.

No new X-1 follow-up is open: the one adopted reuse has a concrete owner and is already complete. RA.8's explicit production-content and deployment gaps remain RA.8/HG-2 concerns; they are not evidence that the Calliope contract adoption is missing.

3. Concordia#

Located homes#

libs/oshun/concordia-integration is only the thin Oshun surface integration, not Concordia's primary implementation. The actual ownership map is:

Concern	Canonical home	Current authority
Domain contracts and policies	`@concordia/contracts`	Case, agreement, consent, privacy, hard-boundary, escalation, reviewer, settlement, evidence, and mediation schemas/algorithms
Runtime coordination	`@concordia/orchestrator`	Fastify health/OpenAPI/discovery gateway plus pure mediation workers, event routing, observability, and tenant admission
Oshun navigation/event/telemetry registration	`@oshun/concordia-integration`	Typed descriptors for `concordia.*` subscriptions, workbench navigation slots, viewer-role projection, and PII-redacted telemetry
User-facing product surface	`studio/concordia-workbench`	Multi-route case intake, evidence, preference, frontier, draft, review, execution, and audit workspace

The orchestrator's mediation algorithms are real and tested, although its case workers are not yet mounted as HTTP case routes. That limitation does not make the package a generic event bus or review widget: the contracts, events, navigation roles, workers, and telemetry categories are all specifically about cooperative mediation cases.

Reuse verdict: do not adopt into the current Rail#

No current Rail channel or kernel responsibility is a mediation or settlement case. Case Files is a solve-first puzzle channel with a fairness receipt; Wonder & Recall is a learning scheduler; their “case” and “review” words do not share Concordia authority. Reusing Concordia's navigation, subscription, or review contracts would duplicate the V10 channel contract and couple a passive, absence-free surface to an unrelated high-context workflow.

If Concordia later becomes an explicitly commissioned Rail channel, that is new product scope: its adapter should project privacy-filtered Concordia state through the canonical V10 contract while deep-linking to the existing workbench. This audit does not create that channel spec or imply consent to show mediation state on an ambient surface.

Verification#

The audit read the production sources, package manifests, public barrels, tests, and relevant V10 consumers rather than relying on generated READMEs. On 2026-07-22, all repository-owned test targets passed:

the six Aphrodite bridges: 679 tests total (121 Hathor, 138 Isis, 98 Lilith, 167 Maya, 79 Nike, 76 Nyx);
@calliope/stage;
@oshun/concordia-integration.

The source census also confirms exactly six Aphrodite bridge directories and no production import from those packages into apps/v10 or libs/v10; the sole adopted orphan is represented by the direct canonical Calliope contract import in the Stage candidate source.