The council — SandScope

SANDSCOPE / COUNCIL

One person, twelve roles, and a rule that made it work

This was built by one person directing an AI through a written charter of named delivery roles. That arrangement collapses into a single agreeable voice unless something stops it, and one rule does most of that work:

A role may not sign off its own work.

The evidence that it held is below: 24 reactions from 10 different roles across 8 real decisions and defects, every one citing an artefact in this repository. Where roles agreed, it says so. Where they disagreed, that is the interesting part and it is printed rather than smoothed over.

The delivery roster

12 roles, each owning something specific and producing something named. A role that owns nothing produces nothing, and a role that produces nothing is a label rather than a function.

Role	Owns	Produces
Business Analyst (BA)	Requirements elicitation, as-is/to-be flows, acceptance criteria	BRD, user stories, process flows, traceability matrix
Product Manager (PM)	Vision, scope, prioritisation, success metrics	PRD, roadmap, release notes
Technical Program Manager (TPM)	Charter, sprint plan, RACI, risks, dependencies, status	This charter, sprint plans, risk register, status reports
Scrum Master (SM)	Ceremonies, impediment removal, velocity	Sprint reviews, retrospectives, burndown
Solutions Architect / FDE	System design, integration design, deployment topology	Tech spec, ADRs, architecture diagrams, C4 models
UX/UI Designer	Design system, layout, motion, accessibility	Design tokens, wireframes, motion spec
Software Engineer (DEV)	Implementation	Source code
SDET	Automated test suites	Unit, integration, contract, e2e tests
QA Lead	Test strategy, Definition of Done, defect triage	Test plan, test report, defect log
DevOps / SRE	CI/CD, environments, observability, incident response	Pipelines, Dockerfile, runbooks, SLOs
Application Security Engineer (AppSec)	Threat model, SAST, DAST, dependency and secret scanning, supply chain, penetration testing, security release gate	Threat model, security pipelines, SBOM, pen-test findings, security sign-off
Technical Writer	User-facing and internal documentation	READMEs, API docs, ADR polish

Where the human sits

The person directing this is not a spectator on it. Every message they send is classified into one of these roles on receipt, because the same sentence carries different authority depending on which hat it arrives under — “the font looks wrong” is an observation, “don’t ship until security passes” is an instruction.

Role	When it applies	Authority
Executive Sponsor	Budget, vision, go/no-go, release authority	Absolute. Overrides all roles.
Product Owner (PO)	Backlog priority, scope decisions, accept/reject stories	Owns the backlog. Sole accepter of stories.
Stakeholder / SME	Domain constraints, business context, external facts	Advisory; becomes a requirement once logged.
UAT Tester	Reviewing built increments against acceptance criteria	Can reject an increment back to the sprint.
Release Authority	Production deployment approval	Deployment is blocked without it.

The review, artefact by artefact

Each entry is a real defect or decision from this repository, with what every role actually said about it. A role that had nothing genuine to say about a given artefact is absent rather than padded in — a committee where everyone comments on everything is a committee producing filler.

The Sprint 2 gate reported 0% false-answer rate. The real rate was 56.6%.

D-001

The refusal gate marked 150 of 265 unanswerable questions as answerable — a 56.6% false-answer rate — on a sample where the Sprint 2 gate had reported 0%.

QA Lead

The test set was written by the implementer, on 22 questions, and every one of

Business Analyst

A 0% error rate reported at a sprint gate is the kind of number that

Technical Program Manager

This is the one that actually changes how I'd read every other

where they divergedQA and BA read this as a process gap in two different places (test

The semantic cache served a stale answer to a correction retry.

D-006

A retry meant to correct an uncited answer instead received the previous, uncited answer from cache — similarity 0.886 against a 0.60 threshold.

Solutions Architect / FDE

Both components — the retry logic and the cache — had correct,

Developer

From inside the retry code, this looks like it should have worked — the retry

QA Lead

This is the sharpest example in the whole log of why running the assembled system

where they divergedthe Architect and QA agree on the root cause but draw different

The console displayed output the governance layer had refused to emit.

D-009

Rendering ignored the run outcome and displayed an assessment the system had already decided not to emit.

Application Security Engineer

This is a governance-bypass bug wearing a UI-bug costume.

UX / UI Designer

From a pure "does this look right" standpoint the page rendered fine —

QA Lead

Confirms the Designer's point from the test side — this wouldn't be caught by

where they divergednone, really — this is a case where three roles converge on the same

Two guards that were built to confirm, not to detect.

D-013D-015

The rate-limit pen test sent 8 requests against a limit of 20 and accepted `all(c >= 400)` as a pass — so a completely dead service reported as correctly rate limited. The README figure-checker searched for values as substrings of the whole file, so `Commits | 54` silently changing to `99` still passed, because "54" also appears elsewhere in the same document.

QA Lead

Both of these are the same defect, twice, in the same sprint, written by the same

Scrum Master

This is a process-health signal more than a testing one. The project's own

Developer

Both bugs are easy to write by accident — a loose assertion, a naive string

where they divergedQA and Developer treat this as a technique problem (test the

Sprints 6 and 7 were worked and shipped without ever being opened.

D-016

No planning ceremony, no plan document — the sprint numbers existed only inside defect-log entries — and a Sprint 5 retrospective had already committed, in writing, to raising exactly this as an impediment if it happened. It happened anyway.

Scrum Master

This is the one I'd flag hardest. It's not that the process broke — it's

Technical Program Manager

From a planning standpoint, work that happens outside a named

Executive Sponsor

The part I'd actually want to know: was the *work* good despite the

where they divergedScrum Master reads this as the more serious failure (a broken

ADR-0003 recorded a pricing claim that was never checked.

D-017ADR-0003ADR-0012

ADR-0003 placed the agent runtime on Hugging Face Docker Spaces "because it is free." Docker Spaces moved behind a paid plan; only Static Spaces remain free, and a Static Space can't run the FastAPI runtime. Three sprints of deployment work targeted a platform that turned out to be impossible at $0.

Solutions Architect / FDE

The choice itself was reasonable at the time it was made. The

Executive Sponsor

Zero infrastructure cost was a constraint I set at the very start of

DevOps / SRE

From where I sit, the practical cost wasn't the ADR being wrong — ADRs get

where they divergedthe Architect frames this as a documentation discipline problem

CI never built the web app; a major framework bump reported 10/10 green while broken.

D-018

No CI job had ever run `next build`. A Dependabot PR taking Next.js from 15 to 16 reported every check green while the production build failed on all seven pages (Turbopack refuses an import path that Webpack tolerated).

QA Lead

This is the purest instance in the log of a check that measures its own existence

DevOps / SRE

From a pipeline-design standpoint, this is a coverage gap that's invisible

Developer

As the person who'd have merged that PR on the strength of a green check suite,

where they divergedno real disagreement here either — all three converge on "the

A three-state chip design, decided this session, over the false-answer budget bar.

`apps/web/src/components/BudgetBar.tsx` originally rendered a two-state chip (`clear`/`not clear` of budget) for the false-answer rate. The measured rate was 4.7% against a 5% budget — passing on the point estimate while its 95% confidence interval (2.9–7.6) crossed the budget line. The two-state chip read "within budget" for a result that was genuinely more ambiguous than that.

Business Analyst

"Within budget" and "the confidence interval is clear of budget" are two

UX / UI Designer

From a pure readability standpoint, a three-state chip is a harder design

Technical Program Manager

This one didn't cost a sprint or get logged as a defect — it was

where they divergedBA and Designer are in real tension here — BA wants maximum

The review process became a tool

Partway through, it became clear the discipline above was worth extracting: pick the methodology first, because Scrum has no Change Control Board and Waterfall has no retrospective, and a role set chosen before a methodology produces a committee that cannot decide anything. Then name a role before each action rather than after, so it constrains the work instead of labelling it.

That became Charter. It started as a skill that replayed this repository’s real history through its roles — mining defect logs, decision records and commits rather than inventing opinions — and everything on this page is its first real output, run against the project that produced it.

It is no longer only that. Charter is now an installable MCP server that anyone can point at any repository: the roles are enforced rather than requested, a role must produce a machine-checkable artifact before it may sign off, and the build record survives on disk across sessions. The roster is plain YAML and keeps growing, and new roles reach existing users through a plugin update rather than a rewrite.

Its most important rule is the one it is easiest to break: never invent the disagreement. If a claim cannot be cited it is dropped rather than dressed up, because manufactured conflict is exactly as useless as manufactured consensus.

charter — install it →github.com/224Sand/charter →the charter →the full retrospective →