docs: align master with canon and policy publication

INTENT.md

@@ -9,7 +9,9 @@
 
 ## One-liner
 
-**The Railiance architecture-definition home — turning evolving repo families, workload models, and substrate realities into a coherent framework vocabulary and boundary model.**
+**The authoritative source for Railiance framework architecture — turning
+evolving repo families, workload models, and substrate realities into coherent,
+reviewable, and permanently publishable boundary decisions.**
 
 ---
 
@@ -57,6 +59,20 @@ organization. They shape how humans and agents coordinate responsibilities,
 reason about workload placement, and evolve operating models without losing the
 ability to scale into more mature security and delivery expectations.
 
+Railiance also participates in two wider governance structures:
+
+* **InfoTechCanon** owns the general semantic models, standards, and repository
+  conventions that Railiance adopts. This repository imports those concepts and
+  applies them to Railiance; it does not redefine the canon by local usage.
+* **`policy-nexus`** owns permanent publication, addressing, history, and
+  currency for estate policy. This repository remains the source and
+  ratification home for its architecture decision records. Publication is
+  generated downstream and never written back here.
+
+That separation matters. Content authority, semantic canon, and publication
+infrastructure are related responsibilities, not one responsibility hidden in
+three repositories.
+
 ---
 
 ## The Mission
@@ -66,7 +82,8 @@ ability to scale into more mature security and delivery expectations.
 To become the **canonical home for Railiance framework architecture** —
 where repository taxonomy, architectural boundaries, execution-model concepts,
 managed workload patterns, substrate concepts, and migration direction are
-defined once and referenced everywhere else.
+defined once, reviewed here, published durably when governing, and referenced
+everywhere else.
 
 This means:
 
@@ -76,6 +93,8 @@ This means:
   **separate and composable**
 * Explorations mature into **stable decisions** before they spread across the
   wider repo landscape
+* Governing ADRs carry enough ownership, revision, status, and review metadata
+  to be published without a second source of truth
 * The framework can support both **early-stage experimentation** and
   **production-grade operation** without collapsing those needs into one vague
   structure
@@ -137,6 +156,27 @@ purpose and operational boundary.
 
 They should not be created merely because a named machine exists.
 
+### 10. Import Canon; Own Railiance Semantics
+
+General concepts such as intent, scope, demand, task, governance, evidence, and
+repository layout come from InfoTechCanon and estate conventions. This repo owns
+their Railiance-specific application: repo-family vocabulary, composition,
+admission, exposure, and cross-repo boundary decisions.
+
+### 11. Author Here; Publish Downstream
+
+Accepted framework ADRs are policy sources. They are authored, reviewed,
+superseded, or withdrawn here and published by `policy-nexus`. Workplans,
+evidence, runbooks, and general documentation remain working material rather
+than becoming policy merely because they are useful.
+
+### 12. Keep Intent, Scope, and Demand Distinct
+
+`INTENT.md` describes the direction and stable purpose. `SCOPE.md` describes
+what the repository currently owns and achieves. Consumer requests and incoming
+proposals are demand signals until reviewed; they do not silently expand scope
+or become committed work.
+
 ---
 
 ## What This Is (Conceptually)
@@ -146,6 +186,8 @@ This repository is:
 * an **architecture-definition home**
 * a **repository taxonomy authority**
 * a home for **framework-level ADRs and conceptual models**
+* the **source repository** for Railiance framework ADRs published through
+  `policy-nexus`
 * a place to define how Railiance repos **compose across multiple axes**
 * a **migration map** from current repo reality toward cleaner framework
   structure
@@ -162,6 +204,9 @@ This repository is not:
 * the forge runtime
 * the application release surface
 * the implementation of the ecosystem graph registry
+* the general semantic canon owned by InfoTechCanon
+* the permanent policy publication surface owned by `policy-nexus`
+* a policy CMS or a second copy of published policy
 * a dumping ground for operational runbooks that belong elsewhere
 
 It is the **place where the framework explains itself**.
@@ -177,6 +222,8 @@ This repository is expected to evolve toward:
 * stronger **boundary guidance** for new repos and migrations
 * better linkage between architecture decisions and `railiance-fabric`
   declarations
+* publication-ready ADR lifecycle metadata and durable downstream policy links
+* explicit, graded adoption of the InfoTechCanon repository-layout convention
 * a repeatable path from **exploration -> ADR -> adopted framework pattern**
 * a clear model for when experimental multi-rail substrates are acceptable and
   when production-grade separation is the better default