railiance-clock/docs/ecosystem.md

Ecosystem placement and registration

Status: proposed owner relationships; registration is repository discovery, not production admission or owner assent.

Concern	Existing owner / intended interaction
Railiance repository/runtime architecture	railiance-master; confirm source ownership and future rapp/reef packaging
Initial authority host	railiance-hosts / railiance-platform / reef-railiance; confirm operational responsibility and UTC discipline
Source/history	Coulomb organization on Forgejo, operated through railiance-forge; retain policy/source/evidence without assigning clock truth to Git dates
Shared discovery/work records	Repo Manager + primary Statehub; derive exact pushed source and stable identifiers
Security architecture	net-kingdom / gate-house; review layer role and trust/validity semantics
Identity and trust material	key-cape / secrets-engine / platform through existing admitted paths; no local credential broker
Decisions / human approvals	flex-auth (access-engine role) / approval-engine; retain their protocols and lifetime authority
Evidence	audit-core; distinguish receipt from event occurrence and bounded translation
Initial consumers	secrets-engine, ops-warden, intelligence-radar; explicitly review adoption rather than substitute local clocks silently
Operational monitoring	railiance-telemetry; quality/uncertainty/epoch metrics

Source contracts to consume

• railiance-master/docs/repository-axes.md
• railiance-master/docs/repo-family-bootstrap-contract.md
• railiance-master/docs/netkingdom-security-consumption-contract.md
• net-kingdom/canon/standards/security-layer-model_v0.7.md and the current adopted successor/companion, verified at implementation time
• the-custodian/canon/standards/repo-classification-standard_v1.0.md
• the-custodian/canon/architecture/adr-007-workplan-identity-and-repo-worker-topology.md
• secrets-engine/docs/approval-consumption.md
• flex-auth/docs/decision-record-contract.md

Paths are ecosystem repository references, not vendored copies. Review current versions and pin consumed contracts before implementation. This seed publishes no speculative layer.yaml, PEP stance-map, capability readiness or runtime grants. The role declaration is a named RCLK-WP-0002 task, not implied compliance.

Registration sequence

1. Establish intent/specification and future work in source; validate identity, links, workplan shape and clean Git state. Select unique RCLK-WP prefix.
2. Commit this baseline in the existing Coulomb Forgejo repository.
3. Register repository and workstation path through statehub register --no-llm, domain infotech, topic custodian, explicit slug/prefix; preserve authored files.
4. Commit generated integration artifacts; run Repo Manager sync --push and require applied/noop exact-commit evidence from primary/railiance01.
5. Send bounded owner handoffs to railiance-master, net-kingdom/gate-house, repo-manager/the-custodian and initial consumers. Store returned message IDs. Request prefix-index reservation and ownership review, without claiming assent.
6. Record final registration receipt in docs/registration.md. Foundation can finish because implementation/review/deployment residuals already live in 0002–0004.

The Coulomb source location and common discovery entry establish ecosystem visibility. Railiance production admission and NetKingdom security adoption remain unresolved until their owners return evidence under RCLK-WP-0002/0004.