From 7db9c3cbf2e6905cf07be83156053be3926297b1 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 24 May 2026 00:25:59 +0200 Subject: [PATCH] docs: define financial fabric architecture --- README.md | 19 +- docs/FabricDiscoveryAndUpdate.md | 289 ++++++++++++++++++ ...AB-WP-0017-financial-fabric-model-reset.md | 241 +++++++++++++++ ...countability-root-discovery-update-loop.md | 213 +++++++++++++ 4 files changed, 757 insertions(+), 5 deletions(-) create mode 100644 docs/FabricDiscoveryAndUpdate.md create mode 100644 workplans/RAIL-FAB-WP-0017-financial-fabric-model-reset.md create mode 100644 workplans/RAIL-FAB-WP-0018-accountability-root-discovery-update-loop.md diff --git a/README.md b/README.md index d35a808..e3817af 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,20 @@ # Railiance Fabric -Railiance Fabric defines the repo-owned declaration model for the Railiance -ecosystem graph. +Railiance Fabric models the durable infrastructure-responsibility graph of the +Railiance netkingdom. -It will hold schemas, seed declarations, validation tools, graph queries, and -State Hub export contracts for services, capabilities, interfaces, -dependencies, and bindings across Railiance repositories. +Fabric is bounded by financial and operational accountability: who pays for the +infrastructure, who is accountable for keeping it alive, and which durable +interfaces create value across fabric and subfabric boundaries. + +It holds schemas, discovery tools, registry services, graph queries, and State +Hub export contracts for services, machines, repositories, deployables, +endpoints, ownership, dependencies, and bindings across Railiance deployment +realities. + +See `docs/FabricDiscoveryAndUpdate.md` for the current architecture direction +for fabric boundaries, king/lord/tenant ownership, discovery, rebuilds, and +update loops. ## Validate Declarations diff --git a/docs/FabricDiscoveryAndUpdate.md b/docs/FabricDiscoveryAndUpdate.md new file mode 100644 index 0000000..9e278f9 --- /dev/null +++ b/docs/FabricDiscoveryAndUpdate.md @@ -0,0 +1,289 @@ +# Fabric Discovery And Update + +## Intent + +`railiance-fabric` models the durable infrastructure-responsibility graph of the +Railiance netkingdom. + +A fabric is not a repository, environment, cluster, deployment scenario, or +security zone. A fabric is the financial and operational responsibility boundary +around infrastructure: who pays for it, who is accountable for it, and who has +the authority to keep it alive. + +The graph exists to answer: + +- what infrastructure, services, repositories, deployables, endpoints, and + machines exist; +- who owns or pays for each node; +- which fabrics and subfabrics contain those nodes; +- which durable interfaces cross ownership boundaries; +- which cross-boundary interfaces provide utility that may carry business value. + +Fabric intentionally stays out of live operational telemetry. It may represent +that a service, host, endpoint, or deployment exists because durable automation +or configuration proves it. It should not represent whether that thing is +currently healthy, loaded, failing, or profitable in the accounting sense. + +## Financial Boundary Terms + +Fabric uses financial responsibility terms for fabric boundaries. + +### King + +The king is responsible for the whole netkingdom. + +The king has the key to the netkingdom. Literally, this means the master key or +at least a relevant key component for secrets, backups, and recovery paths across +the infrastructure under the netkingdom. + +The king also holds the legal and contractual relationship with all lords and +tenants. Even when responsibility is delegated, the king remains the actor that +can ultimately restore, recover, govern, or terminate the netkingdom. + +### Lord + +A lord pays for a fabric. + +A lord is accountable for a durable infrastructure-responsibility boundary. In +the current Railiance setup there is one effective fabric because one actor pays +for all infrastructure. Additional fabrics appear when the responsibility to pay +for a coherent infrastructure boundary changes. + +### Tenant + +A tenant pays for restricted use of a subfabric. + +A tenant is not the root payer for the whole fabric. A tenant receives bounded +access to utility inside a subfabric and may consume services or interfaces +provided by a lord, by the king, or by another tenant-facing utility. + +## Fabrics, Subfabrics, And Views + +### Fabric + +A fabric is a durable responsibility boundary. Membership changes when financial +or operational responsibility changes, not when a service is redeployed, a repo +is refactored, a host is replaced, or an environment name changes. + +Criteria for establishing a fabric: + +- there is a lord who pays for the infrastructure in that boundary; +- the boundary can be discovered from durable infrastructure, deployment, or + contractual evidence; +- the boundary remains stable across ordinary deployment and development churn; +- ownership changes imply a meaningful change to who is accountable for cost, + continuity, recovery, and utility delivery. + +### Subfabric + +A subfabric is a delegated responsibility or tenancy partition within a fabric. + +Subfabrics are useful when a tenant receives restricted access to infrastructure +or utility while the parent fabric remains under a lord or king. A subfabric may +eventually become a separate fabric if payment, control, recovery, and legal +responsibility move to another lord. + +### View + +A view is a diagnostic or informational slice through the graph. + +Views can filter by repository, service, environment, machine, endpoint, tenant, +workstream, deployment stack, or business capability. Views do not define fabric +membership and should not mutate fabric boundaries. + +### Environment + +An environment such as local, dev, staging, production, or lab is a deployment +classification inside a fabric. It is not a fabric by itself. + +### Deployment Scenario + +A deployment scenario is a realized or planned arrangement of services, +machines, endpoints, automation, and configuration. It belongs inside a fabric +or subfabric but does not define the financial boundary. + +## Ownership Rule + +Every node in the Fabric graph must carry owner information. + +Ownership may be explicit on the node or inherited from the containing fabric or +subfabric, but it must be resolvable. Nodes without resolvable ownership are +incomplete because Fabric cannot explain who is accountable for their cost, +continuity, recovery, or utility. + +Ownership should identify the relevant king, lord, tenant, or delegated operator +where applicable. Operators and maintainers may be represented as supporting +actors, but they do not replace the financial boundary terms unless they also +pay for or legally own the responsibility boundary. + +## Cross-Boundary Edges + +Edges may cross fabric and subfabric boundaries. + +These edges are especially important. They are where one owned boundary consumes +utility from another owned boundary. They are also where business value can +appear: paid access, cost recovery, shared platform utility, tenant-facing +interfaces, or contractual service delivery. + +Fabric should treat cross-boundary interfaces as first-class graph facts. A +cross-boundary utility edge should be able to identify: + +- provider owner; +- consumer owner; +- provider fabric or subfabric; +- consumer fabric or subfabric; +- exposed endpoint, contract, service, or utility; +- durable evidence for the relationship; +- expected payment or business model when known; +- metering basis when known. + +The existence of a cross-boundary interface belongs in Fabric. Live usage, +current health, latency, revenue events, and incident state belong to telemetry, +accounting, or operational systems outside the Fabric core. + +## Cost And Profit Center Attribution + +Cost centers and profit centers are accounting attributions. They are not fabric +boundaries by themselves. + +A cost center may be evidence that a responsibility boundary exists, especially +when it corresponds to a lord who pays for infrastructure. However, the fabric +boundary is still established by financial and operational accountability, not +by the accounting label alone. + +Cost and profit center attribution may overlap with fabrics and subfabrics: + +- one fabric may contain many cost centers; +- one tenant may span several cost centers; +- one cost center may include nodes from multiple subfabrics; +- one shared service may allocate cost across several tenants or cost centers; +- one cross-boundary utility may be cost-bearing for one actor and + profit-bearing for another. + +Fabric should therefore support optional accounting attribution on nodes and +edges without allowing that attribution to redefine containment: + +- node cost center; +- node profit center; +- edge cost allocation model; +- edge profit attribution; +- payment schema; +- metering or allocation basis when known; +- attribution validity period when known. + +This lets Fabric build cost-center and profit-center views while preserving the +durability of fabric membership. A node moving from one cost center to another +does not necessarily move fabrics. A node moves fabrics only when financial or +operational responsibility for the infrastructure boundary changes. + +Useful accounting views include: + +- all infrastructure attributed to a cost center; +- all cross-boundary utility edges attributed to a profit center; +- tenant-facing utilities without a payment schema; +- shared services with unresolved allocation; +- owned nodes without cost-center attribution; +- expensive or critical infrastructure with no visible value interface. + +## Discovery Approach + +Fabric discovery should start from accountability roots, not from arbitrary repo +ownership declarations. + +Useful roots include: + +- the king and current netkingdom inventory; +- lords and their fabrics; +- tenants and their subfabrics; +- State Hub attached repositories and known host paths; +- Gitea organizations and repository URLs; +- deployment automation repositories; +- Docker, Compose, Kubernetes, systemd, reverse proxy, and infrastructure + manifests; +- backup, recovery, and secret-management evidence; +- service endpoint and API specifications; +- CI/CD and release automation that proves deployables and deployment targets. + +The scanner follows these roots outward to discover durable evidence of nodes +and edges. Repository-local facts can still help identify deployables, APIs, and +artifacts, but repository-owned declarations should not be the default source of +truth for external fabric relations. + +## Rebuild From Scratch + +A full rebuild should be deterministic enough to repeat and provenance-rich +enough to review. + +Recommended phases: + +1. Establish the netkingdom root and current king. +2. Register known lords, fabrics, tenants, and subfabrics. +3. Register durable discovery roots for each fabric and subfabric. +4. Crawl deployment automation, infrastructure manifests, repo inventories, + service configs, and endpoint contracts. +5. Store raw evidence with source paths, URLs, timestamps, scanner versions, and + content hashes. +6. Normalize identities across host paths, repository URLs, image names, service + names, endpoint names, and deployment names. +7. Build candidate graph nodes and edges. +8. Resolve or flag ownership for every node. +9. Promote accepted candidates into a versioned fabric snapshot. +10. Export the accepted snapshot to State Hub as a read model. + +## Keeping The Model Up To Date + +Fabric freshness should be based on durable configuration and automation changes, +with scheduled rescans as a safety net. + +Rescan triggers include: + +- deployment automation changes; +- infrastructure manifest changes; +- State Hub attached repository inventory changes; +- repository changes that affect deployables, APIs, images, service names, + endpoint contracts, ports, or deployment configuration; +- tenant or lord changes; +- backup, recovery, or secret-root changes; +- manual operator requests; +- scheduled periodic rebuilds. + +Normal source-code edits do not necessarily change the Fabric graph. Fabric +should focus on changes that alter durable topology, ownership, deployment, +interfaces, or cross-boundary utility. + +Each update should compare new discovery output with the previous accepted +snapshot and produce a delta. The delta should distinguish: + +- added, changed, and removed nodes; +- added, changed, and removed edges; +- changed ownership; +- changed fabric or subfabric membership; +- new or removed cross-boundary utility interfaces; +- ambiguous identity merges that need review; +- discovered nodes without resolvable ownership. + +## Boundary With Security Terms + +Fabric should avoid using security-zone language for its core concepts. + +Terms such as realm, domain, tenant realm, identity realm, and security domain +are useful in systems such as Microsoft environments or Keycloak, but they carry +security and identity-management semantics. Fabric may later relate to those +systems as discovered evidence, but the core Fabric concept is financial and +operational responsibility, not identity or access-control topology. + +For now, use: + +- king, lord, and tenant for financial responsibility actors; +- fabric and subfabric for durable responsibility boundaries; +- view for diagnostic graph slices; +- environment for deployment classification. + +## State Hub Role + +State Hub coordinates work and stores a readable projection of the Fabric graph. +It should not be the primary author of Fabric topology. + +`railiance-fabric` discovers, normalizes, versions, and exports Fabric snapshots. +State Hub imports those snapshots so agents and operators can ask practical +questions about work, ownership, dependencies, and cross-boundary utility. diff --git a/workplans/RAIL-FAB-WP-0017-financial-fabric-model-reset.md b/workplans/RAIL-FAB-WP-0017-financial-fabric-model-reset.md new file mode 100644 index 0000000..adfb412 --- /dev/null +++ b/workplans/RAIL-FAB-WP-0017-financial-fabric-model-reset.md @@ -0,0 +1,241 @@ +--- +id: RAIL-FAB-WP-0017 +type: workplan +title: "Financial Fabric Model Reset" +domain: railiance +repo: railiance-fabric +status: ready +owner: codex +topic_slug: railiance +created: "2026-05-23" +updated: "2026-05-23" +state_hub_workstream_id: "39cc363c-6e2a-46a2-bd19-cee7ff6fc149" +--- + +# RAIL-FAB-WP-0017 - Financial Fabric Model Reset + +## Goal + +Adapt `railiance-fabric` to the revised Fabric intent captured in +`docs/FabricDiscoveryAndUpdate.md`. + +Fabric should model durable infrastructure-responsibility boundaries rather +than repo-owned external relation declarations. The core model must understand +the Railiance netkingdom, king/lord/tenant financial actors, fabric and +subfabric containment, resolvable node ownership, cross-boundary utility +interfaces, and optional cost/profit center attribution. + +## Background + +The current Fabric implementation grew from repo-owned declarations and a +canon-aligned graph export. That was useful for bootstrapping, but it now +misplaces authority for external relations: a repository cannot sustainably own +all deployment contexts, tenant relations, or cross-boundary utility edges in +which it participates. + +The updated architecture establishes these principles: + +- a fabric is bounded by financial and operational accountability; +- the king is responsible for the whole netkingdom and holds the relevant + recovery/secrets/backups authority; +- a lord pays for a fabric; +- a tenant pays for restricted use of a subfabric; +- every node needs resolvable ownership; +- cross-boundary utility edges are first-class value interfaces; +- cost/profit centers are accounting attributions and view dimensions, not + fabric boundaries; +- Fabric should avoid security-zone terms such as realm or domain for its core + concepts. + +This workplan resets the Fabric contract and internal model so later discovery +work can rebuild the graph from accountability roots and deployment automation. + +## T01 - Audit Current Model Assumptions + +```task +id: RAIL-FAB-WP-0017-T01 +status: todo +priority: high +state_hub_task_id: "3d259e3c-5534-4b6a-930a-d085d3db57e4" +``` + +Inventory the current assumptions that must change. + +Scope: + +- schema files and declaration shapes under `schemas/` and `fabric/`; +- Python model classes and validators; +- registry storage tables and snapshot materialization; +- State Hub export payload shape; +- tests and fixtures that assume repo-owned declarations are the primary graph + source; +- documentation that still describes Fabric as repo-owned external relation + declarations. + +Done when: + +- affected files and APIs are listed; +- compatibility risks are documented; +- the migration approach for existing accepted graph data is explicit; +- follow-on tasks have enough detail to implement without rediscovering the + whole codebase. + +## T02 - Define The VNext Fabric Semantic Contract + +```task +id: RAIL-FAB-WP-0017-T02 +status: todo +priority: high +state_hub_task_id: "8bbab878-0bff-4302-a925-15a8aceabf9b" +``` + +Define the next graph contract for Fabric snapshots and exports. + +Required concepts: + +- netkingdom root; +- actor nodes for king, lord, tenant, and supporting operators/stewards; +- fabric and subfabric containment; +- node ownership and inherited ownership resolution; +- cross-boundary utility interfaces; +- optional cost center and profit center attribution on nodes and edges; +- evidence and provenance fields for every discovered or accepted fact; +- schema versioning and compatibility metadata. + +Done when: + +- schemas or contract documents describe the vNext shape; +- existing canonical node/edge concepts are mapped to the new model or marked + for retirement; +- unresolved ownership and ambiguous containment have explicit representation; +- examples cover the current single Railiance fabric, a tenant subfabric, and a + cross-boundary utility edge. + +## T03 - Refactor Core Validation And Registry Materialization + +```task +id: RAIL-FAB-WP-0017-T03 +status: todo +priority: high +state_hub_task_id: "7ff1c162-f778-4ab4-9e09-a512a54b2f68" +``` + +Update validation and registry materialization around the new contract. + +Requirements: + +- enforce resolvable ownership for graph nodes; +- distinguish containment, ownership, accounting attribution, and diagnostic + views; +- support fabric and subfabric membership without treating environments as + fabrics; +- represent cross-boundary utility edges as first-class accepted graph edges; +- retain evidence/provenance and confidence/review state; +- keep old graph data readable long enough for migration or controlled reset. + +Done when: + +- model classes, validators, registry materialization, and tests support the + new contract; +- invalid missing-owner cases fail or are flagged according to the contract; +- existing snapshot/export code can emit the vNext model. + +## T04 - Update The State Hub Export Contract + +```task +id: RAIL-FAB-WP-0017-T04 +status: todo +priority: high +state_hub_task_id: "d10f120d-746d-468d-b208-d946b54c2707" +``` + +Revise the State Hub export payload so State Hub can import the improved Fabric +model as a read model. + +Requirements: + +- include fabric/subfabric identity and containment; +- include owner actor identity and owner role; +- include accounting attribution fields when present; +- include cross-boundary utility metadata; +- include schema/export version metadata; +- preserve enough current canonical fields for compatibility where practical; +- document required State Hub changes for `STATE-WP-0051`. + +Done when: + +- export schema and sample payloads are updated; +- current State Hub import limitations are documented; +- compatibility tests cover both old baseline import behavior and the new + vNext export behavior, or intentionally document a controlled breaking reset. + +## T05 - Seed The Current Railiance Netkingdom Baseline + +```task +id: RAIL-FAB-WP-0017-T05 +status: todo +priority: medium +state_hub_task_id: "b8430050-94a8-43f6-9b3c-7928c5c6bb69" +``` + +Create the initial accepted model for the current Railiance responsibility +boundary. + +Requirements: + +- one root Railiance netkingdom; +- current king actor; +- current lord/fabric boundary reflecting that one actor pays for the current + infrastructure; +- initial default ownership rules for discovered nodes; +- placeholders for future tenant/subfabric modeling; +- no security-zone terminology in the core model. + +Done when: + +- the current graph can resolve ownership for all accepted nodes; +- the baseline explains why there is currently one effective fabric; +- future tenant subfabrics can be added without changing the root fabric + definition. + +## T06 - Update Documentation, Fixtures, And Operator Guidance + +```task +id: RAIL-FAB-WP-0017-T06 +status: todo +priority: medium +state_hub_task_id: "93a8a79e-877f-48c1-888e-0fb50c8de75b" +``` + +Bring docs and fixtures in line with the reset model. + +Requirements: + +- update README and affected architecture/registry/export docs; +- document the migration from repo-owned declarations to accountability-root + discovery; +- update sample graph exports and validation fixtures; +- document the handoff to State Hub and to the discovery/update-loop workplan; +- keep `docs/FabricDiscoveryAndUpdate.md` as the architecture anchor. + +Done when: + +- docs no longer present repo-owned external declarations as the default source + of truth; +- tests and examples exercise king/lord/tenant, ownership, fabric/subfabric, + cost/profit attribution, and cross-boundary utility edges; +- operator guidance explains how to refresh State Hub after a reset export. + +## Acceptance + +- Fabric has a documented vNext contract aligned with + `docs/FabricDiscoveryAndUpdate.md`. +- Every accepted graph node has resolvable ownership. +- Fabric and subfabric membership is distinct from environments, deployment + scenarios, and views. +- Cross-boundary utility interfaces are first-class graph edges. +- Cost/profit centers are optional accounting attributions and view dimensions. +- The State Hub export schema is updated or a controlled reset path is + documented. +- Existing tests are updated or replaced with coverage for the new model. + diff --git a/workplans/RAIL-FAB-WP-0018-accountability-root-discovery-update-loop.md b/workplans/RAIL-FAB-WP-0018-accountability-root-discovery-update-loop.md new file mode 100644 index 0000000..774d00f --- /dev/null +++ b/workplans/RAIL-FAB-WP-0018-accountability-root-discovery-update-loop.md @@ -0,0 +1,213 @@ +--- +id: RAIL-FAB-WP-0018 +type: workplan +title: "Accountability Root Discovery And Update Loop" +domain: railiance +repo: railiance-fabric +status: ready +owner: codex +topic_slug: railiance +created: "2026-05-23" +updated: "2026-05-23" +state_hub_workstream_id: "651185b5-83fe-4aef-b29d-617b2bc48c7a" +--- + +# RAIL-FAB-WP-0018 - Accountability Root Discovery And Update Loop + +## Goal + +Build the discovery and update mechanism that keeps Fabric current from durable +accountability roots and deployment automation, rather than from repo-owned +external relation declarations. + +This workplan depends on the semantic direction from +`RAIL-FAB-WP-0017-financial-fabric-model-reset.md`. + +## Background + +Fabric should be able to rebuild the Railiance graph from scratch by starting +with the netkingdom, king/lord/tenant actors, fabric/subfabric boundaries, +State Hub attached repositories, Gitea URLs, deployment automation, service +configuration, infrastructure manifests, secret/backup evidence, and endpoint +contracts. + +The update loop must stay below live telemetry. It should track durable +configuration and automation changes that alter topology, ownership, deployment, +interfaces, or cross-boundary utility. + +## T01 - Define Discovery Root Manifest + +```task +id: RAIL-FAB-WP-0018-T01 +status: todo +priority: high +state_hub_task_id: "38ae49fb-ce21-489c-ba67-7f76ab4febc9" +``` + +Define a manifest format for accountability-root discovery. + +The manifest should be able to register: + +- netkingdom root; +- king, lord, and tenant actors; +- fabric and subfabric boundaries; +- State Hub attached repo inventory roots; +- Gitea organization or repository roots; +- deployment automation roots; +- known host paths; +- infrastructure, backup, recovery, and secret-root evidence sources; +- refresh cadence or trigger hints. + +Done when: + +- manifest schema and examples exist; +- the current Railiance one-fabric baseline can be represented; +- the format can add future tenant subfabrics without changing the top-level + fabric criterion. + +## T02 - Implement Durable Evidence Discovery Adapters + +```task +id: RAIL-FAB-WP-0018-T02 +status: todo +priority: high +state_hub_task_id: "09246f06-10db-4c6c-9cb3-f2808fdbaa38" +``` + +Implement or adapt scanners for durable evidence sources. + +Initial adapters should cover: + +- State Hub attached repositories and host paths; +- local/Gitea repository identity; +- Dockerfiles and Compose files; +- Kubernetes, systemd, reverse proxy, and service config where present; +- deployment scripts and CI/CD references; +- API specs and endpoint contracts; +- backup, recovery, and secret-management evidence where safely discoverable. + +Done when: + +- each adapter emits provenance-rich raw evidence; +- evidence distinguishes durable existence/configuration from live operational + state; +- adapters can run against the current local Railiance workspace. + +## T03 - Build Evidence Store And Identity Normalization + +```task +id: RAIL-FAB-WP-0018-T03 +status: todo +priority: high +state_hub_task_id: "2a79938f-13e2-41b4-b692-74420d31bec4" +``` + +Persist discovery output and normalize identities before graph promotion. + +Requirements: + +- scanner run metadata; +- source paths, URLs, timestamps, scanner versions, and content hashes; +- stable identity candidates for repos, deployables, services, machines, + endpoints, fabrics, subfabrics, and actors; +- duplicate/ambiguous identity detection; +- candidate graph generation separate from accepted graph snapshots. + +Done when: + +- raw evidence can be inspected independently from accepted graph state; +- identity normalization produces reviewable candidates; +- repeated scans produce deterministic identities for unchanged sources. + +## T04 - Add Ownership Resolution And Review Flow + +```task +id: RAIL-FAB-WP-0018-T04 +status: todo +priority: high +state_hub_task_id: "670be2c2-6bec-4534-ae6a-ab0186ce0a8d" +``` + +Resolve ownership for discovered nodes and flag gaps. + +Requirements: + +- inherit owner from containing fabric/subfabric when evidence is sufficient; +- support explicit owner evidence from manifests or deployment automation; +- flag nodes with unresolved ownership; +- flag ambiguous fabric/subfabric containment; +- expose review/accept operations for candidates; +- preserve reviewer decisions across rescans when evidence identity is stable. + +Done when: + +- no accepted node can silently lack ownership; +- unresolved or ambiguous nodes are visible before promotion; +- review decisions survive ordinary rescans. + +## T05 - Implement Snapshot Deltas And Freshness Triggers + +```task +id: RAIL-FAB-WP-0018-T05 +status: todo +priority: medium +state_hub_task_id: "c2f28b34-de32-4090-8782-5d00541b9018" +``` + +Add an update loop that detects meaningful Fabric changes. + +Triggers should include: + +- deployment automation changes; +- infrastructure manifest changes; +- State Hub attached repository inventory changes; +- repository changes affecting deployables, APIs, service names, ports, + endpoint contracts, images, or deployment configuration; +- lord, tenant, cost/profit center, backup, recovery, or secret-root changes; +- manual operator rebuilds; +- scheduled periodic rescans. + +Done when: + +- scanner runs can compare against the previous accepted snapshot; +- deltas distinguish added/changed/removed nodes and edges; +- ownership, containment, accounting attribution, and cross-boundary utility + changes are highlighted; +- unchanged sources are not needlessly promoted. + +## T06 - Bootstrap The Current Railiance Rebuild + +```task +id: RAIL-FAB-WP-0018-T06 +status: todo +priority: high +state_hub_task_id: "0d05ee40-0823-473f-9c87-0ed964e8900c" +``` + +Run the new discovery/update loop against the current Railiance workspace. + +Requirements: + +- rebuild from the accountability root manifest; +- produce a reviewable candidate graph; +- accept the baseline into a versioned Fabric snapshot; +- export the snapshot for State Hub; +- document unresolved gaps as follow-up workplans rather than hiding them. + +Done when: + +- the current Railiance graph can be rebuilt from durable roots; +- ownership is resolved or explicitly flagged for every node; +- State Hub can import the resulting export after `STATE-WP-0051`; +- operator docs explain how to rerun the rebuild and update loop. + +## Acceptance + +- Fabric discovery starts from accountability roots and deployment automation. +- Raw evidence, candidate graph state, and accepted graph snapshots are + separated. +- The update loop detects durable topology, ownership, deployment, interface, + and cross-boundary utility changes. +- Live telemetry remains out of scope. +- The current Railiance baseline can be rebuilt from scratch and exported. +