CH(Ai)SE / LEAD Harness Model
What are Chaise and Lead?
- CH(Ai)SE = Collaborative Human-AI Standards Environment
- LEAD = Lineage-Enforced Agentic Delivery
This diagram shows the structural relationship and communication flows between all entities in the CH(Ai)SE / LEAD system, including their roles, authorities, and protocols for coordinating portfolio governance with project execution.
Entity Model Diagram
Portfolio Scope Entities
Operator
Role:
Apex authority. Human decision-maker.
Authority:
Resolves all conflicts between roles. Sets product direction. Authorizes major decisions.
Communication:
Sends direction and prioritization to both Chaise and Counsel. Both report back on portfolio decisions.
Does NOT:
Execute feature work. Manage day-to-day sprints. Stay at strategy level only.
Chaise
Role:
Cross-project methodology owner. Maintains the CH(Ai)SE framework, canon, and standards.
Authority:
Defines HOW projects work (governance, ceremonies, roles). Receives ceremonial reports from all projects at sprint phase closes.
Communication:
Coordinates with Counsel on canon changes. Pushes standards down to Lead via Canon & Standards line.
Key Deliverables:
Methodology docs, canon versioning, cross-project consistency rules.
Counsel
Role:
Read-only verification layer. Reviews canon changes, checks lineage consistency, enforces methodology compliance.
Authority:
Gate-keeper, never directs. Can only recommend or reject changes; does not make product decisions.
Communication:
Coordinates with Chaise on canon quality. Receives escalations from Lead when domain-truth questions arise.
Key Deliverables:
Canon verdicts, compliance audits, lineage verification.
Project Scope Entities
Lead
Role:
Project architect. One Lead per project, at every tier. Its stated Position (e.g. Lead · Phase II · Step C) says which step it is working, and it crosses steps only through written artifacts. Owns the card pipeline, ceremonies, and release decisions.
Authority:
Sets priorities within Operator's direction. Decides what ships when. Escalates scope/priority disputes to Operator.
Work by Phase II step:
- Steps A–B (Initiate Sprint, Card Grooming): Sprint Goal, DoD baseline, cards groomed to Sprint Ready
- Step C (Card Execution): live DoD ledger, emergent cards
- Steps D–E (Sprint Review, Release Integration): review triage, release, retrospective
Communication:
Receives canon & standards from Chaise. Orchestrates Board dispatch order. Reports ceremony results back to Chaise at phase close.
Board
Role:
Sprint execution layer. Dispatches cards to Devs, checks merge gates, merges to staging, and hands each merged card to Walker.
Authority:
Picks the Dev for each lane Lead has set. Decides whether a PR may land on staging. Cannot reorder priorities: Lead does that. Never merges to main and never sets Done.
Communication:
Receives the card pipeline from Lead. Pushes card scope to Devs via Dispatch. Receives the PR with the Dev's QA verdict before merging, then hands the merged card to Walker.
Key Constraint:
Does NOT re-check ACs a QA sub-agent has passed, and does NOT walk merged cards while a Walker is reachable. Walks only as fallback for Walker, or as part of its own job at a tier with no Walker.
Devs
Role:
Builds features under Board dispatch. Two modes: Standard (judge ambiguity in flight) or Literal (execute frozen contract exactly).
Authority:
Implement scope as written. Escalate blockers to Board; escalate scope questions to Lead if frozen contract breaks.
Communication:
Receives dispatch from Board. Runs a QA sub-agent in its own session before the PR opens (QA: PASS or FAIL), then opens the PR to Board. Takes rework back from Walker on WALK: FAIL.
Execution:
Devs execute one card at a time within declared file scope, in Standard (judgment) or Literal (frozen contract) mode.
Walker
Role:
Runtime verification. One per project at Tier 3 (optional at Tier 2 with staging, none at Tier 1). Walks every merged card on staging and posts the verdict.
Authority:
Owns the walk verdict: WALK: PASS, WALK: FAIL, or WALK: PENDING SIGN-IN. On a failed walk, moves the card back to In Progress. Never merges, dispatches or sets Done.
Communication:
Receives each merged card from Board's hand-off. Posts the verdict on the card. Sends failed walks back to the Dev as rework and tells Board.
Key Pattern:
Separation of concerns. The entity that merges a card does not verify that merge. The Dev's QA sub-agent checks before merge; Walker checks after.
Communication Protocols
| From | To | Protocol | Purpose |
|---|---|---|---|
| Operator | Chaise, Counsel | Direction & Authority | Set strategic constraints and priorities |
| Chaise | Counsel | Portfolio Coordination | Review canon changes, verify consistency |
| Chaise | Lead | Canon & Standards | Push methodology and rules; pull learnings |
| Lead | Board | Orchestrates | Set card priority order; gate dispatch decisions |
| Board | Devs | Dispatch | Assign cards; set scope and DoD |
| Devs | Board | PR + QA verdict | Open the PR after the QA sub-agent passes; raise Block, Escalate or Spike |
| Board | Walker | Hand-off | Card merged and applied to staging, ready to walk |
| Walker | Board, Devs | Walk Verdict | Post WALK: PASS or FAIL; a failed walk returns to the Dev as rework |
Reporting Cadence
Lead reports to Chaise as Linear Documents or comments, by Phase II step:
- Step B (grooming complete): Goal, DoD baseline, schedule
- Step C (mid-sprint): Blockers + emergent cards
- Steps D–E (review and release): Metrics, learnings, released version
Authority Escalation Paths
Scope or priority dispute
→ Escalates to Operator: Only Operator resolves conflicts between roles
Domain-truth finding (IL, canon, methodology)
→ Escalates to Chaise: Domain questions go to governance owner
Execution blocker (blocked dev, missing env)
→ Escalates to Board: Board owns execution gate and resource decisions
Card-quality gap (bad AC, vague scope)
→ Escalates to Lead: Lead owns card definition