docs(intent): center workload operations and bound rein-*

State that Railiance organizes workload operations along the four repo
axes, and that glas-harness reins are adjacent rather than a fifth family.
Keep the ADR-0007 coverage fact in SCOPE so intent stays aspirational.

Assistant: grok
Assistant-Session: 01a04c9f-cd6b-7741-bce0-f1d9d1b3c3bc

INTENT.md

@@ -13,6 +13,10 @@
 evolving repo families, workload models, and substrate realities into coherent,
 reviewable, and permanently publishable boundary decisions.**
 
+Railiance itself is a systematic way to organize the **operation of
+workloads**: who owns them, how they run, how they are packaged, and where
+they are bound. This repository exists to keep that language canonical.
+
 ---
 
 ## Why This Exists
@@ -36,6 +40,40 @@ Railiance before that language hardens accidentally inside implementation repos.
 
 ---
 
+## What The Framework Organizes
+
+Railiance organizes **workload operations**, not merely repositories.
+
+A **workload**, in the Railiance-specific sense, is a managed running
+deployable. Human commands, credential patterns, broker actions, approvals,
+and infrastructure resources that are not themselves deployables are not
+workloads. InfoTechCanon supplies the general landscape vocabulary; this
+framework owns the Railiance application: every such workload is operated
+through four composable axes.
+
+| Prefix | Axis | Question |
+| --- | --- | --- |
+| `railiance-*` | ownership | Who owns this capability? |
+| `rail-*` | execution contract | How does this workload run? |
+| `rapp-*` | managed package | What exactly is being packaged and operated? |
+| `reef-*` | substrate | Where is it bound, and as what operational reality? |
+
+Those families are complementary answers about one workload. They are not
+competing repo types. The detailed model, creation rules, and composition
+semantics live in `docs/repository-axes.md` and the accepted framework ADRs.
+The coverage rule — what is and is not a workload — belongs to the rapp
+declaration contract; this file names the object of the architecture.
+
+**Adjacent, not a fifth axis.** `rein-*` repos are glas-harness agent harness
+backends. Their name was chosen to echo `rail-*`; that echo is analogical,
+not taxonomic. Agentic session semantics — session loops, tool policy,
+harness routing, and model selection — belong to glas-harness and its reins.
+This repository does not define a `rein-*` family. When a rein is installed
+and operated as a managed service, it is a workload like any other and is
+packaged, executed, and bound through `rapp-*`, `rail-*`, and `reef-*`.
+
+---
+
 ## Operating Context
 
 Railiance does not exist in isolation.
@@ -80,10 +118,10 @@ three repositories.
 > *Where we are going.*
 
 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, reviewed here, published durably when governing, and referenced
-everywhere else.
+where the language of workload operations, repository taxonomy, architectural
+boundaries, execution-model concepts, managed packaging, substrate concepts,
+and migration direction is defined once, reviewed here, published durably when
+governing, and referenced everywhere else.
 
 This means:
 
@@ -91,6 +129,8 @@ This means:
 * New repo families and framework terms are introduced through **clear decisions**
 * Ownership, execution mode, workload identity, and substrate identity remain
   **separate and composable**
+* Adjacent families such as glas-harness `rein-*` remain **named and bounded**,
+  not absorbed as extra Railiance axes
 * Explorations mature into **stable decisions** before they spread across the
   wider repo landscape
 * Governing ADRs carry enough ownership, revision, status, and review metadata
@@ -111,7 +151,8 @@ across the ecosystem.
 ### 2. Shared Vocabulary Is Infrastructure
 
 Terms such as `railiance-*`, `rail-*`, `rapp-*`, and `reef-*` are not cosmetic.
-They shape ownership, tooling, and operator understanding.
+They are the vocabulary of workload operations. They shape ownership, tooling,
+and operator understanding.
 
 ### 3. Separate Axes Cleanly
 
@@ -158,10 +199,11 @@ 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.
+General concepts such as intent, scope, demand, task, governance, evidence,
+repository layout, and workload come from InfoTechCanon and estate conventions.
+This repo owns their Railiance-specific application: repo-family vocabulary,
+workload coverage, composition, admission, exposure, and cross-repo boundary
+decisions.
 
 ### 11. Author Here; Publish Downstream
 
@@ -188,7 +230,8 @@ This repository is:
 * 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 place to define how **workload operations compose** across ownership, rail,
+  rapp, and reef
 * a **migration map** from current repo reality toward cleaner framework
   structure
 
@@ -208,6 +251,11 @@ This repository is not:
 * 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
+* the glas-harness `rein-*` family, or the owner of agentic session semantics
+* a place to invent a fifth repository family for LLM or agentic work
+
+A rein deployed as a managed service is a workload on the four Railiance axes.
+The harness contract is not this repository's.
 
 It is the **place where the framework explains itself**.
 
@@ -220,6 +268,8 @@ This repository is expected to evolve toward:
 * clearer **repository-family definitions** and lifecycle rules
 * stable **rail**, **rapp**, and **reef** contracts
 * stronger **boundary guidance** for new repos and migrations
+* a durable distinction between Railiance workload axes and adjacent harness
+  families such as `rein-*`
 * better linkage between architecture decisions and `railiance-fabric`
   declarations
 * publication-ready ADR lifecycle metadata and durable downstream policy links
@@ -232,4 +282,4 @@ This repository is expected to evolve toward:
 
 ## Guiding Question
 
-> **How can Railiance define its own structure clearly enough that every new repo, rail, managed workload, and substrate increases capability without increasing ambiguity, even as the ecosystem grows from exploratory operation into production-grade responsibility?**
+> **How can Railiance organize the operation of workloads clearly enough that every new ownership boundary, rail, managed package, and substrate increases capability without increasing ambiguity, even as the ecosystem grows from exploratory operation into production-grade responsibility?**

SCOPE.md

@@ -18,7 +18,10 @@ framework ADRs, declaration schemas, and cross-repo architecture workplans.
 `railiance-master` currently owns the Railiance-specific meaning of the four
 repository axes: ownership repos (`railiance-*`), execution contracts
 (`rail-*`), managed workload packages (`rapp-*`), and substrate boundaries
-(`reef-*`).
+(`reef-*`). **Workload**, in that Railiance-specific sense, is a managed
+running deployable under rapp coverage (`ADR-0007`); human acts, credentials,
+broker actions, and non-deployable infrastructure resources remain outside
+that meaning.
 
 The current implementation includes:
 
@@ -62,6 +65,8 @@ not own every implementation implied by them.
   `reef-*` repository
 - Platform services, application releases, forge runtime, and Fabric graph
   implementation owned by their concrete repositories
+- glas-harness `rein-*` harness contracts and agentic session semantics; a
+  deployed rein is a workload on the four axes, not a fifth Railiance family
 
 ---
 
@@ -98,6 +103,8 @@ publication addressing are completed.
 - Work belongs entirely inside one implementation repository
 - Work is operational execution of an already-settled boundary
 - A workload-specific decision has no framework-wide consequence
+- The request is about glas-harness session, tool, or rein-backend semantics
+  rather than how a deployed rein is packaged, executed, or bound as a workload
 - The request is raw demand that has not yet been reviewed for purpose and scope
   fit