railiance-master/demand/README.md

2.4 KiB

Architecture Demand Intake

This directory is the unreviewed intake surface for proposed changes to the Railiance framework architecture. It implements the InfoTechCanon distinction between a DemandSignal and committed work:

  • a file here records a request, opportunity, conflict, or observed scope pressure;
  • it is not a task and carries no implementation commitment;
  • review compares it with INTENT.md, current SCOPE.md, existing ADRs, and the purpose of the requesting consumer;
  • only an accepted disposition may create or amend a workplan;
  • resolved demand leaves this directory and moves to history/ with its review trail intact.

State Hub messages are coordination transport, not this directory's source of truth. Capture a message here only when it presents genuine architecture demand that needs review. Do not mirror the inbox wholesale.

File convention

Pending demand uses YYYY-MM-DD-NNN-<slug>.md and this minimum shape:

---
id: RMASTER-DEMAND-YYYY-MM-DD-NNN
type: demand-signal
status: unreviewed
received: "YYYY-MM-DD"
source: "operator | agent/repo | discovery"
consumer: "who needs the outcome"
---

Each record answers:

  1. What is being requested or observed?
  2. What consumer purpose would it serve?
  3. How does it fit the producer intent?
  4. Does it expose a current-scope defect, future-scope pressure, or work that belongs elsewhere?
  5. What evidence supports it?

Review dispositions

  • accepted — create or link the repo-local workplan, then archive the demand record as history/YYMMDD-demand-<slug>.md.
  • routed — name the owning repository and durable handoff evidence, then archive the record.
  • deferred — state the trigger or missing evidence; keep the record here only while it remains genuinely unreviewed, otherwise archive it.
  • rejected — record why it conflicts with intent, scope, or an accepted decision, then archive it.

Review changes the demand record's status and adds reviewer, review date, purpose fit, scope pressure, disposition rationale, and resulting work ID. Raw demand must never move directly into task status without that trail.

Worked example

The first completed intake is history/260818-demand-canon-policy-alignment.md. It records the operator request that became RMASTER-WP-0024 and demonstrates the full signal → review → workplan → history path.