generated from coulomb/repo-seed
214 lines
6.4 KiB
Markdown
214 lines
6.4 KiB
Markdown
---
|
|
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.
|
|
|