Solution Pack: GenUI AI Full-Stack Copilot
Architecture summary
Decision: launch a bounded workflow copilot, not a general assistant. Use permission-filtered retrieval, typed event protocol, component registry, schema validation, tool side-effect classes, eval gates, trace correlation, cost budgets, accessibility review, and layered kill switches.
Workflow sketch
Boundary decisions
| Boundary | Decision |
|---|---|
| scope | one workflow, one user role, one data domain for beta |
| components | allowlist registry with versioned schemas |
| tools | read-only and draft-only tools first |
| retrieval | permission filters before context assembly |
| citations | required for factual claims |
| side effects | approval plus server policy, not approval alone |
| fallback | deterministic workflow remains available |
Eval gates
Required suites:
- happy path
- ambiguous prompt
- missing data
- stale data
- unauthorized source
- prompt injection in retrieved content
- invalid UI schema
- tool timeout
- approval rejection
- keyboard/focus generated UI
- mobile slow network
- cost/latency budget
ADR bundle
ADR 1: Bounded workflow over general assistant
Context: a general assistant is hard to evaluate, authorize, support, and explain.
Decision: launch one workflow for one role and one data domain. Expansion requires eval and incident evidence.
Consequences:
- smaller launch scope
- clearer product value
- easier evals and permissions
- slower broad capability expansion
Verification:
- task completion against deterministic baseline
- correction/rejection reason trend
- workflow failure rate
ADR 2: Registry-only generated UI
Context: arbitrary generated UI creates security, accessibility, and support risk.
Decision: models may propose versioned component schemas from an allowlist. Deterministic validation decides what renders.
Consequences:
- safer UI generation
- slower component expansion
- schema compatibility must be managed
Verification:
- generated UI validation failure rate
- component accessibility fixtures
- fallback rendering tests
ADR 3: Tool side effects require server policy
Context: human approval is necessary but not sufficient; a model can propose unauthorized or unsupported actions.
Decision: tools are exposed by workflow scope, side-effect class, role, and policy. Approval is a UX gate on top of server authorization, not a replacement.
Consequences:
- more backend workflow complexity
- stronger auditability
- safer expansion to write actions
Verification:
- unauthorized tool evals
- audit log completeness
- idempotency for side effects
- approval denial handling
Review gates
| Gate | Evidence |
|---|---|
| Product value | baseline comparison and success metric |
| Retrieval | permission filtering, source freshness, citation coverage |
| Registry | component schemas, validation, fallbacks, accessibility fixtures |
| Tools | side-effect classes, policy, idempotency, approval, audit |
| Evals | happy path, malicious, ambiguous, stale, unauthorized, invalid UI |
| Observability | trace connects UI, model, retrieval, tool, user outcome, cost |
| Rollback | kill switches by workflow, model, retrieval, tool, component, streaming |
Rollout plan
- Internal dogfood with trace review.
- Beta for one role and one workflow.
- Weekly fixture additions from real failures.
- Expand component registry only after validation failure rate stabilizes.
- Add draft-only tools before external side effects.
- Require separate review before any destructive or financial tool.
Strong reviewer concerns
- Do not let the model return arbitrary HTML or React.
- Do not retrieve sources before permission filtering.
- Do not treat approval as authorization.
- Do not ship without eval gates and kill switches.
- Do not measure only model quality; measure task success, correction, cost, latency, and accessibility.
Portfolio artifacts
- workflow boundary diagram
- component registry contract
- eval matrix
- trace schema
- tool policy
- kill-switch matrix
- launch review
- incident runbook