Custom solutions vary widely in risk based on what they do, what data they touch, who operates them, and the context they run in. Without a consistent intake, teams either over-rotate (slow) or under-review (risk exposure).
Design principle: we do not "re-review everything." We identify which incremental obligations are triggered by the specific solution and run only the reviews that are actually required.
Capture minimal structured inputs (what it does, data, hosting/ops, context, system impact).
Auto-route using decision rules; flag red-lines that require high assurance.
Derive which incremental reviews are triggered (privacy, security, legal, ops, AI governance).
Assemble only the artifacts required for the selected option (short pack vs full pack).
Approve, approve with constraints, or stop. Record decision and conditions for delivery.
| Option | When it's used | Typical SLA | Minimum outputs |
|---|---|---|---|
| Option A — Rapid Triage | Bounded, client-operated; guidance/advisory; read-only; non-sensitive data; low public-interest context. | 1–2 business days | Routing decision + basic constraints + minimal evidence (intake summary). |
| Option B — Standard Intake | Regulated contexts, personal data, provider-hosted pilots, gated actions, or meaningful workflow/system impact. | ~5 business days to decision (typical) | Decision + triggered worklist + short Evidence Pack (data map, hosting boundary, oversight model). |
| Option C — Full Proposal | Government/critical, managed service, persistent provider operation, automatic decisions, write/execute in core systems. | 2–6+ weeks (scope dependent) | Formal approvals + full Evidence Pack + risk acceptance (where required) + operating model. |
The process is designed to keep Option C rare and intentional. Most work should land in A or B if scoped properly.
| Driver | Executive definition |
|---|---|
| Decision role | Is it advising humans, taking actions with human gates, or acting automatically? |
| Human involvement | Do humans review every case, exceptions only, or not routinely? |
| Operations model | Who operates it day-to-day (client vs provider), and is it persistent or a pilot? |
| Data type | Test/business data vs personal data vs sensitive/regulated data. |
| Context | Commercial vs regulated vs government/critical environments. |
| System impact | Read-only vs updates to workflows/documents vs writes/executes in core systems. |
Any of these automatically requires Option C — Full Proposal (or an explicit executive override):
| Role | Accountability |
|---|---|
| Submitter | Provides accurate intake details and confirms scope boundaries. |
| Solution owner | Owns the technical/design response and evidence pack. |
| Risk reviewers | Provide approvals only when triggered (privacy, security, legal, etc.). |
| Decision owner | Confirms lane decision and constraints; escalates where needed. |
After ~30–60 intakes, tune the thresholds and hard flags based on observed outcomes.