Phase B — Business Architecture
The capabilities Schema-to-Screen introduces or changes, the value stream from a request to a governed screen, the end-to-end process with its decision points, and who is accountable for what.
B1 · Business capability mapLevel-1 capabilities with level-2 detail, heat-mapped by change
new introduced by the platform · enhanced existing capability materially changed · existing integrated as-is. Reflows to one column on narrow screens.
1 · Demand & intake new
Turning business prose into a typed, checkable use-case spec.
2 · Schema knowledge new
Knowing the schema well enough to retrieve the right seven tables out of three thousand.
3 · Data governance enhanced
Classification and entitlements become executable inputs rather than documents.
4 · Contract generation new
Composing a GraphQL slice and its persisted operations from a subgraph and the policy catalog.
5 · Experience generation new
Producing the on-demand screen as a spec, and custom components as reviewed exceptions.
6 · Verification new
Deterministic proof that an artifact is safe to publish.
7 · Review & publish new
Human judgment applied to contracts, with evidence, in minutes.
8 · Runtime delivery enhanced
Serving every use case through one graph and one runtime, with authorization compiled in.
9 · Change & operations new
Making schema, policy and model change computable rather than discovered.
10 · Platform governance existing
The enterprise controls the platform plugs into rather than replaces.
B2 · Value streamFrom a business question to a governed screen
Each stage names the value it adds, who participates, and the KPI that tells you the stage is healthy. Machine stages are minutes; the two human stages are the designed bottleneck.
Request
Value: a question stated in the business's words.
Who: requester.
KPI: requests/week.
Specify
Value: a typed spec with actors, questions, allowed actions.
Who: intake agent, requester.
KPI: clarification rounds; refusal rate.
Ground
Value: the right subgraph, with join paths and citations.
Who: Scout over the catalog.
KPI: subgraph precision/recall; ambiguity rate.
Compose
Value: a GraphQL slice and a UI spec, policies applied.
Who: composers.
KPI: first-pass gate success; escape-hatch rate.
Verify
Value: deterministic proof of safety.
Who: verifier, sandbox.
KPI: gate failure taxonomy; time in gates.
Approve
Value: accountable human judgment on evidence.
Who: domain owner; Finance for writes.
KPI: reviews/hour; rejection reasons.
Publish
Value: one more slice in one graph; one more spec in one runtime.
Who: registry, runtime.
KPI: time request → live.
Operate
Value: screens that stay correct as the schema moves.
Who: crawler, gates, owners.
KPI: drift → re-verify latency; degraded count.
B3 · Process flow (swimlanes)The generation run with its decision points, retries and parking
Solid arrows are the happy path; dashed arrows are loops (clarify, retry) and the drift trigger. Every loop is bounded by the supervisor; every dead end parks with a person.
B4 · Actor / role → capability matrixWho is responsible, who approves, who is consulted, who is informed
| Capability | Requester | Platform agents | Data owner | Domain reviewer | Security | Platform eng | Business user |
|---|---|---|---|---|---|---|---|
| Demand & intake | R | R | — | I | — | — | C |
| Schema knowledge | — | R | A (descriptions) | — | C | R (crawler) | — |
| Data governance | — | I | R | C | A | C | — |
| Contract generation | — | R | I | I | C (policy catalog) | C | — |
| Experience generation | C | R | — | I | — | A (custom components) | C |
| Verification | — | R | — | I | A (gate set) | R (sandbox) | — |
| Review & publish | I | — | C | A | C | R (publish) | I |
| Runtime delivery | — | — | — | — | C | R | uses |
| Change & operations | I | R (re-verify) | A (drift) | I | I | R | I |
| Platform governance | — | — | — | — | A | R | — |
B5 · Business services catalogThe services the platform offers, and to whom
| Business service | Description | Consumer | Service level (target) |
|---|---|---|---|
| Use-case request | Submit a business question; receive a typed spec or a clarifying question | Requesters | Spec or question within minutes; ≤2 clarification rounds before parking |
| Governed screen delivery | A published, versioned screen and its GraphQL slice for an approved use case | Domain teams | Machine time in minutes; review SLA owned by the domain |
| Catalog stewardship | Owner review of table descriptions, classification coverage reports, drift notices | Data owners | Crawl per schedule and on DDL events; drift notice within one crawl cycle |
| Policy enforcement | Entitlements compiled into every query; classified fields policed on every slice | Security, compliance | 100% policy coverage before publish; zero unscoped operations reachable |
| Proposal handling | Write actions delivered as proposals into the owning system's approval queue | Finance, operations owners | No direct writes; proposal status visible in the originating screen |
| Evidence & audit | Every run traced; every publish recorded against its release unit; any screen's SQL reproducible | Audit, security | Trace retained per policy; reproduction on demand |
| Component registry | Reviewed custom components available to every future spec | Developers, composers | Escape-hatch rate tracked; registry growth reviewed monthly |