Phase A — Architecture Vision
What Schema-to-Screen is for, who it serves, and the one-picture solution concept the rest of the ADM elaborates. Outputs: solution concept diagram, stakeholder map, driver → outcome chain, business scenario, scope and constraints.
A0 · Vision statementThe architecture in one paragraph
Any legitimate business question over the enterprise's data becomes a governed, published screen in minutes — generated by agents that only ever see a retrieved subgraph of the schema, verified by deterministic gates, approved by a person, and served through one graph where authorization is compiled into every query.
- Read-mostly business screens across ~12 archetypes (lists, 360s, queues, exceptions, reconciliations, dashboards…)
- Write actions as proposals with platform-enforced approval
- Thousands of tables across many databases; thousands of use cases
- Hybrid UI: spec-driven by default, reviewed custom components by exception
- Warehouse-scale aggregation and analytics (composed in from the warehouse, not generated)
- Complex transactional business logic (stays in coded services, exposed as subgraphs)
- Autonomous writes to systems of record
- Free-form text-to-SQL for end users
- Classification coverage is a prerequisite for enabling a domain
- Generation runs against sample data only; never production
- TypeScript end-to-end; provider-agnostic LLM access with pinned versions
- Reference implementation over a scaled public sample database (≥3,000 tables, synthetic data)
A1 · Solution concept diagramDemand → governed generation → one graph → business users
The high-level shape a sponsor needs to agree to before Phases B–D elaborate it: two halves of one platform (generation and runtime) standing on two catalogs (schema and policy), between business demand and the systems of record.
A2 · Stakeholder mapWho cares about what — and which view answers them
Each stakeholder's concerns map to a view in this set. Power/interest classification drives who signs the architecture contract (Phase G).
| Stakeholder | Key concerns | Power / interest | Answered by |
|---|---|---|---|
| CISO / security architecture | Where authorization is enforced; PII exposure; prompt-injection blast radius; what the model can see; auditability | High / High — signs off | Data security view · Runtime sequence · Gates |
| Data owners / stewards | Catalog quality; who reviews table descriptions; classification coverage; blast radius of schema changes | Medium / High | Data lifecycle · Change management |
| Product owners / domain leads | Time from request to screen; fit of generated screens; what they can and cannot ask for | Medium / High | Value stream · Business scenario |
| Platform engineering | Supergraph composition at 1,000 slices; drift; runtime load; escape-hatch governance | High / High | Application architecture · Technology |
| Compliance / internal audit | Evidence: who approved what, against which release unit; reproducibility of any screen's SQL | Medium / Medium | Release unit entity · Governance |
| FinOps | Model spend per use case; database load from generated queries; cache effectiveness | Low / Medium | Technology catalog (cost notes) |
| Application developers | When to use the escape hatch; how coded services compose in; DSL limits | Medium / Medium | Components · Capability map |
| Business users | Screens that answer the question; nothing they aren't allowed to see; actions that feel safe | Low / High | Business scenario |
| Executive sponsor | Backlog reduction; risk posture; cost; a defensible story for regulators | High / Medium | Driver → outcome chain · Roadmap |
A3 · Motivation chainDrivers → goals → objectives → measurable outcomes
- Screen backlog grows faster than any team can clear it
- Text-to-SQL and copy-paste RAG bypass the authorization model
- Regulators ask "who could see this" and nobody can answer from a document
- Schema changes break screens silently
- Make the business data surface generative and governed
- Enforce authorization structurally, once, for every generated artifact
- Keep human judgment on approving, not writing
- Make change computable
- Retrieval-selected subgraphs ≤30 tables regardless of schema size
- 100% policy coverage of classified fields before publish; entitlements compiled into SQL
- Deterministic gates + mandatory review on first publish and writes
- Catalog versioning with automatic re-verification on drift
- Minutes of machine time per use case; ~10 reviews/hour/reviewer
- Zero unscoped queries reachable at runtime (measured in CI)
- Escape-hatch rate below ~20% of screens
- Every schema change yields a computed list of affected use cases within one crawl cycle
A4 · Business scenarioCustomer Success account-risk 360 — the worked case used across every phase
CS managers reconcile overdue invoices and open support tickets across three systems by hand. A screen was requested eighteen months ago. It never reached the top of any backlog.
Requester: CS operations lead. Users: cs.manager, cs.analyst. Reviewers: CS domain owner (read paths), Finance owner (the write path). Data owners of crm, finance, support.
Prose request → typed spec (archetype detail-360-with-actions) → Scout returns 7 of 3,000+ tables with join paths → slice with policies on 6 classified fields + one proposal mutation → UI spec with two routes → nine gates pass → two approvals → published. Machine time in minutes; human time in two reviews.
A CS analyst without pii:contact sees contact names but null emails. A manager sees only their territories — composed into the SQL, not filtered after. "Propose credit hold" creates a proposal Finance approves in its own queue; nothing is placed directly.
Time to published screen · gate report (policy coverage 100%, cost under ceiling) · zero PII exposure on sample scan · reviewer decisions recorded against the release unit · drift on finance.invoice re-verifies this use case automatically.