Add railiance-fabric conformance support pack

This commit is contained in:
2026-05-23 05:35:11 +02:00
parent 076285c8c0
commit fdf7793eb8
34 changed files with 1787 additions and 82 deletions

View File

@@ -0,0 +1,71 @@
id: conformance/railiance-fabric
title: Railiance Fabric Canon Conformance Pack
status: candidate
consumer: railiance-fabric
purpose: Prepare canon-side support for refactoring railiance-fabric entity and edge capture for conformance, reasoning, and visualization.
created_by_workplan: ITC-WP-0008
conformance_mode: pre-refactor
canon_anchors:
- model/landscape
- model/network
- model/data
- model/devsecops
- model/observability
- model/governance
- model/security
- model/task
- model/purpose-demand-extension
- standard/tagging
- profile/small-saas
pack_components:
capture_criteria: evaluations/railiance-fabric/entity-edge-capture-criteria.yaml
mapping_expectations: evaluations/railiance-fabric/mapping-expectations.yaml
visualization_examples: evaluations/railiance-fabric/visualization-examples.yaml
consumer_workplan_brief: evaluations/railiance-fabric/consumer-workplan-brief.md
capture_surfaces:
- landscape entities and their ownership boundaries
- runtime resources, deployments, repositories, pipelines, and artifacts
- network zones, endpoints, reachability, paths, and flows
- datasets, datastores, lineage, residency, and processing purpose
- observability signals, alerts, incidents, dashboards, and evidence
- governance policies, controls, reviews, exceptions, and decisions
- security findings, exposure, attack paths, and mitigations
- tasks created from gaps, findings, remediation, or evolution pressure
- consumer purposes, demand signals, purpose fit, and scope pressure
readiness_gates:
- id: gate/entity-identity
title: Captured nodes have stable canonical identity.
required: true
expects:
- Every canonical node has id, kind, title, source, owner or steward, provenance, and canon anchor.
- id: gate/edge-semantics
title: Captured edges distinguish canonical relationships from display-only edges.
required: true
expects:
- Every canonical edge has type, source, target, source artifact, confidence, and evidence status.
- id: gate/visualization-boundary
title: Visualization metadata does not become canon meaning.
required: true
expects:
- Layout, color, cluster, rank, and collapse edges are marked display_only.
- id: gate/evidence-trace
title: Claims can be traced to evidence, signal, or explicit gap.
required: true
expects:
- Captured entities and edges carry evidence references or known gap status.
- id: gate/purpose-pressure
title: Fabric demand can feed canon evolution without silently changing scope.
required: true
expects:
- Railiance-fabric declares purposes, use cases, demand signals, purpose fit, and requested evolution.
output_expectations:
- completed Canon Interface Card for railiance-fabric
- entity category mapping export
- edge category mapping export
- clean graph examples and corrected bad graph examples
- evidence bundle or explicit evidence gaps
- consumer-side workplan created in the railiance-fabric repo
non_goals:
- Refactor railiance-fabric in this repo.
- Choose railiance-fabric storage, graph database, UI, or rendering technology here.
- Treat visual grouping as canonical meaning.

View File

@@ -0,0 +1,56 @@
---
id: conformance/railiance-fabric/consumer-workplan-brief
title: Railiance Fabric Consumer Workplan Brief
status: candidate
consumer: railiance-fabric
conformance_pack: conformance/railiance-fabric
---
# Railiance Fabric Consumer Workplan Brief
## Purpose
Use this brief as the seed for a railiance-fabric repo workplan. The refactor
and implementation workplan belongs in the railiance-fabric repository, not in
InfoTechCanon.
## Goal
Refactor railiance-fabric entity and edge capture so graph visualization stays
useful while canonical meaning remains clean, traceable, and reusable.
## Canon Inputs
- `infospace/evaluations/railiance-fabric/conformance-pack.yaml`
- `infospace/evaluations/railiance-fabric/entity-edge-capture-criteria.yaml`
- `infospace/evaluations/railiance-fabric/mapping-expectations.yaml`
- `infospace/evaluations/railiance-fabric/visualization-examples.yaml`
- `infospace/agent/templates/canon-interface-card.template.yaml`
- `infospace/examples/consumer-purpose-portfolio.yaml`
## Workplan Tasks For Railiance Fabric
1. Complete a Canon Interface Card for railiance-fabric.
2. Export current entity categories and map them to canon anchors.
3. Export current edge types and split them into canonical relationships,
candidate relationships, and display-only graph edges.
4. Add evidence state to captured nodes and edges.
5. Implement or document clean graph examples and bad-shape corrections.
6. Record purpose fit, scope pressure, and requested canon evolution.
## Expected Outputs
- completed interface card,
- entity capture mapping,
- edge capture mapping,
- display-only edge inventory,
- evidence-state inventory,
- visualization examples,
- list of railiance-fabric refactor tasks,
- list of canon evolution requests.
## Non-Goals
- Do not choose UI or graph database technology from this canon workplan.
- Do not turn layout, color, cluster, or highlight metadata into canon meaning.
- Do not change InfoTechCanon without a canon-side EvolutionRequest.

View File

@@ -0,0 +1,137 @@
id: conformance/railiance-fabric/entity-edge-capture-criteria
title: Railiance Fabric Entity And Edge Capture Criteria
status: candidate
consumer: railiance-fabric
conformance_pack: conformance/railiance-fabric
entity_categories:
- id: service
canon_anchor: model/landscape
required_fields: [id, kind, title, owner, lifecycle_state, source, provenance]
expectation: Captures business, application, or technical service without collapsing runtime deployment details.
- id: software-system
canon_anchor: model/landscape
required_fields: [id, kind, title, owner, repository_refs, deployment_refs, source]
expectation: Captures software system or component boundary.
- id: runtime-resource
canon_anchor: model/landscape
required_fields: [id, kind, title, environment, platform, observed_state, source]
expectation: Captures workload, cluster, namespace, container, VM, or cloud resource as runtime reality.
- id: source-repository
canon_anchor: model/devsecops
required_fields: [id, kind, title, owner, url_or_path, default_branch, source]
expectation: Captures source-of-truth repository without treating it as the deployed service.
- id: pipeline
canon_anchor: model/devsecops
required_fields: [id, kind, title, repository_ref, trigger, produced_artifacts, source]
expectation: Captures delivery workflow that produces artifacts or deployments.
- id: deployment
canon_anchor: model/devsecops
required_fields: [id, kind, title, environment, artifact_ref, runtime_ref, source]
expectation: Captures deployment record as a change from source artifact into runtime.
- id: endpoint
canon_anchor: model/network
required_fields: [id, kind, title, address_or_dns, protocol, owner, source]
expectation: Captures network reachability point without hiding service or runtime ownership.
- id: network-zone
canon_anchor: model/network
required_fields: [id, kind, title, boundary, policy_refs, source]
expectation: Captures segmentation or trust boundary.
- id: flow
canon_anchor: model/network
required_fields: [id, kind, source_ref, target_ref, protocol, direction, evidence_ref]
expectation: Captures observed or declared communication separately from a generic dependency.
- id: datastore
canon_anchor: model/data
required_fields: [id, kind, title, data_domain, classification, owner, source]
expectation: Captures storage or data product boundary.
- id: telemetry-signal
canon_anchor: model/observability
required_fields: [id, kind, title, signal_type, observed_entity_ref, source]
expectation: Captures metric, log, trace, alert, incident, dashboard, or operational evidence.
- id: policy
canon_anchor: model/governance
required_fields: [id, kind, title, scope, owner, source]
expectation: Captures directive or rule governing an entity, edge, or capture claim.
- id: control
canon_anchor: model/security
required_fields: [id, kind, title, objective, applies_to, evidence_refs]
expectation: Captures preventive, detective, corrective, or compensating control.
- id: evidence
canon_anchor: model/observability
required_fields: [id, kind, title, evidence_type, supports, date_or_version]
expectation: Captures support for graph claims and conformance assertions.
- id: task
canon_anchor: model/task
required_fields: [id, kind, title, work_type, state, owner, source]
expectation: Captures remediation, mapping, review, or refactor work created from graph gaps.
- id: consumer-purpose
canon_anchor: model/purpose-demand-extension
required_fields: [id, kind, title, consumer, use_case, demand_signals]
expectation: Captures why railiance-fabric needs the canon and where it pressures scope.
canonical_edge_categories:
- type: part_of
source_category: runtime-resource
target_category: software-system
expectation: Structural containment or composition.
- type: depends_on
source_category: service
target_category: service
expectation: Logical dependency, not necessarily network flow.
- type: deploys
source_category: deployment
target_category: runtime-resource
expectation: Delivery event or deployment record places artifact into runtime.
- type: built_from
source_category: deployment
target_category: source-repository
expectation: Runtime state traces back to source.
- type: exposes
source_category: service
target_category: endpoint
expectation: Service is reachable through an endpoint.
- type: flows_to
source_category: flow
target_category: endpoint
expectation: Network flow target remains distinct from dependency.
- type: reads_or_writes
source_category: service
target_category: datastore
expectation: Data access has direction, purpose, and evidence.
- type: observed_by
source_category: runtime-resource
target_category: telemetry-signal
expectation: Signal observes a concrete entity.
- type: governed_by
source_category: service
target_category: policy
expectation: Governance artifact applies to captured object or relation.
- type: implements
source_category: control
target_category: policy
expectation: Control implements or satisfies policy or objective.
- type: evidenced_by
source_category: control
target_category: evidence
expectation: Evidence supports a control, claim, review, or edge.
- type: creates_task
source_category: evidence
target_category: task
expectation: Finding, gap, or review creates work only after triage.
display_only_edge_categories:
- type: grouped_with
expectation: Visual cluster membership; must not be used as a canonical relationship.
- type: near
expectation: Layout adjacency; never a semantic dependency.
- type: same_color_group
expectation: Rendering classification; use Tag when semantic classification is needed.
- type: collapsed_into
expectation: View aggregation; canonical nodes and edges must remain recoverable.
- type: highlight_path
expectation: Temporary user-selected route in a visualization, not graph truth.
capture_rules:
- Canonical edge types must be drawn from registered mappings or explicitly flagged as candidate.
- Display-only edges must use display_only: true and must not appear in conformance claims.
- Every node and edge must carry source and provenance, even when confidence is low.
- Unknown concepts should be captured as gaps with candidate mapping, not forced into nearest canon concept.
- Relationship direction must be explicit and stable.
- Evidence gaps should create review or mapping work instead of silent graph cleanup.

View File

@@ -0,0 +1,144 @@
id: conformance/railiance-fabric/mapping-expectations
title: Railiance Fabric Mapping Expectations
status: candidate
consumer: railiance-fabric
conformance_pack: conformance/railiance-fabric
first_models:
- id: model/landscape
reason: Primary owner of services, software systems, runtime resources, environments, dependencies, and landscape claims.
expected_categories:
- service
- software-system
- runtime-resource
- endpoint
- id: model/network
reason: Owner of topology, connectivity, reachability, zones, paths, and flows.
expected_categories:
- endpoint
- network-zone
- flow
- id: model/data
reason: Owner of datastores, datasets, data movement, lineage, residency, and processing purpose.
expected_categories:
- datastore
- dataset
- data-flow
- id: model/devsecops
reason: Owner of repositories, pipelines, artifacts, releases, deployments, attestations, and delivery evidence.
expected_categories:
- source-repository
- pipeline
- deployment
- artifact
- id: model/observability
reason: Owner of telemetry, signals, alerts, incidents, dashboards, investigations, and operational evidence.
expected_categories:
- telemetry-signal
- incident
- dashboard
- evidence
- id: model/governance
reason: Owner of policy, decision, control objective, review, exception, evidence expectations, and acceptance of gaps.
expected_categories:
- policy
- decision
- review
- exception
- id: model/security
reason: Owner of findings, exposure, attack paths, mitigations, security incidents, and controls.
expected_categories:
- control
- finding
- exposure
- mitigation
- id: model/purpose-demand-extension
reason: Owner of purpose fit, demand signal, scope pressure, and evolution requests from railiance-fabric.
expected_categories:
- consumer-purpose
- demand-signal
- purpose-fit
- scope-pressure
mapping_requirements:
- id: req/canonical-anchor
expectation: Every railiance-fabric entity category maps to one canon artifact and one proposed owner concept.
- id: req/edge-direction
expectation: Every canonical edge has direction, source category, target category, relationship type, and evidence status.
- id: req/display-separation
expectation: Layout, grouping, highlighting, and collapsed view relationships are display metadata, not canon edges.
- id: req/evidence-state
expectation: Each captured node and edge has evidence_state of observed, declared, inferred, proposed, or gap.
- id: req/purpose-fit
expectation: Unmapped fabric concepts create PurposeFit and EvolutionRequest candidates instead of silent scope changes.
candidate_edge_mapping:
- railiance_edge: service_depends_on_service
canon_relationship: depends_on
canon_anchor: model/landscape
evidence_required:
- source artifact
- reason for dependency
- confidence
- railiance_edge: workload_exposes_endpoint
canon_relationship: exposes
canon_anchor: model/network
evidence_required:
- endpoint declaration or observation
- protocol
- scope
- railiance_edge: service_reads_datastore
canon_relationship: reads_or_writes
canon_anchor: model/data
evidence_required:
- data access direction
- processing purpose
- data classification
- railiance_edge: deployment_runs_resource
canon_relationship: deploys
canon_anchor: model/devsecops
evidence_required:
- deployment record
- artifact version
- environment
- railiance_edge: signal_observes_resource
canon_relationship: observed_by
canon_anchor: model/observability
evidence_required:
- signal source
- resource reference
- collection time or version
- railiance_edge: policy_governs_service
canon_relationship: governed_by
canon_anchor: model/governance
evidence_required:
- policy reference
- scope
- owner
- railiance_edge: finding_affects_service
canon_relationship: affects
canon_anchor: model/security
evidence_required:
- finding record
- affected asset
- severity or impact
consumer_interface_card_expectations:
consumed_artifacts:
- model/landscape
- model/network
- model/data
- model/devsecops
- model/observability
- model/governance
- model/security
- model/task
- model/purpose-demand-extension
- standard/tagging
produced_concepts:
- FabricEntity
- FabricEdge
- CaptureSource
- DisplayEdge
- CanonicalEdgeCandidate
- VisualizationView
requested_extensions:
- stable relationship vocabulary for graph capture
- evidence-state vocabulary for captured edges
- visualization boundary guidance for display-only edges

View File

@@ -0,0 +1,91 @@
id: conformance/railiance-fabric/visualization-examples
title: Railiance Fabric Visualization Examples
status: candidate
consumer: railiance-fabric
conformance_pack: conformance/railiance-fabric
examples:
- id: clean-service-runtime-slice
title: Clean service to runtime slice
purpose: Show service, deployment, runtime, endpoint, data, signal, policy, and evidence as distinct nodes.
nodes:
- id: service/billing-portal
category: service
canon_anchor: model/landscape
- id: deployment/production
category: deployment
canon_anchor: model/devsecops
- id: runtime/billing-namespace
category: runtime-resource
canon_anchor: model/landscape
- id: endpoint/billing-api
category: endpoint
canon_anchor: model/network
- id: datastore/subscription-ledger
category: datastore
canon_anchor: model/data
- id: signal/access-review
category: telemetry-signal
canon_anchor: model/observability
- id: policy/tenant-isolation
category: policy
canon_anchor: model/governance
- id: evidence/access-review
category: evidence
canon_anchor: model/observability
edges:
- source: deployment/production
type: deploys
target: runtime/billing-namespace
display_only: false
- source: service/billing-portal
type: exposes
target: endpoint/billing-api
display_only: false
- source: service/billing-portal
type: reads_or_writes
target: datastore/subscription-ledger
display_only: false
- source: runtime/billing-namespace
type: observed_by
target: signal/access-review
display_only: false
- source: service/billing-portal
type: governed_by
target: policy/tenant-isolation
display_only: false
- source: policy/tenant-isolation
type: evidenced_by
target: evidence/access-review
display_only: false
- id: bad-shape-service-runtime-collapse
title: Bad shape where service and runtime collapse
bad_shape:
problem: One node named billing-portal carries service, deployment, namespace, endpoint, and evidence semantics.
why_bad: The graph cannot distinguish declared service boundary from deployed runtime and observed evidence.
correction:
- Split service, deployment, runtime resource, endpoint, and evidence into distinct nodes.
- Connect them with deploys, exposes, observed_by, and evidenced_by edges.
- Preserve a display cluster only as display_only metadata.
- id: bad-shape-display-edge-as-canon
title: Bad shape where display grouping becomes canon
bad_shape:
problem: A same_color_group edge is used to claim ownership or dependency.
why_bad: Rendering choices become semantic claims and pollute downstream reasoning.
correction:
- Replace ownership with owned_by when evidence exists.
- Replace dependency with depends_on or flows_to only when source evidence supports it.
- Keep same_color_group as display_only true.
- id: bad-shape-flow-dependency-confusion
title: Bad shape where network flow equals dependency
bad_shape:
problem: Observed traffic is captured as service_depends_on_service without policy, endpoint, or protocol context.
why_bad: A transient flow may not be an intentional dependency.
correction:
- Capture flow as Flow with protocol, source, target, and evidence.
- Create depends_on only when a declared or inferred dependency has separate support.
- Link both to evidence and confidence.
visualization_rules:
- Canonical graphs must be recoverable without layout metadata.
- Views may collapse or cluster nodes, but collapsed source nodes and edges must remain retrievable.
- Display attributes may include color, group, rank, x, y, icon, collapsed, highlighted, and hidden.
- Display attributes must not be used by validation as proof of ownership, dependency, reachability, policy, or evidence.