63 lines
2.8 KiB
Markdown
63 lines
2.8 KiB
Markdown
# Scirium v2 Scope
|
|
|
|
Status: PLANNED
|
|
Applies to: v2 (risk-tiered actions on top of v1)
|
|
|
|
## 1. What v2 Adds
|
|
|
|
v2 keeps everything in v1 (grounded, cited, read-only Q&A) and adds a single new capability class: risk-tiered actions. v2 never removes the v1 grounding rails.
|
|
|
|
## 2. Risk-Tiered Actions
|
|
|
|
Actions are grouped by risk and ship in that order. Reporting first, low-risk writes second, and never anything above the approved tier.
|
|
|
|
| Tier | Examples | Ships | Autonomy |
|
|
|---|---|---|---|
|
|
| 0 | Q&A only (v1) | v1 | None |
|
|
| 1 | Reporting: summaries, compliance checklists, document search reports | v2 first | None beyond read |
|
|
| 2 | Low-risk writes: draft a policy section, draft an email reply, update an internal FAQ | v2 second | Propose, then approve, then narrow audited write |
|
|
| 3 | Higher-risk writes and integrations | v3 | Still gated, broader by tier |
|
|
|
|
## 3. The Propose-Approve-Audit Gate
|
|
|
|
Every action in v2 and later passes through three steps. This gate is permanent.
|
|
|
|
1. Propose. The agent drafts the action and shows exactly what it would do: the target system, the record, and the exact change.
|
|
2. Approve. A human with the right role approves or rejects. No action executes without an explicit approval.
|
|
3. Audit. The executed action is written narrowly (only the approved change), and the full record is logged: who proposed, who approved, what changed, when.
|
|
|
|
| Gate step | What it enforces |
|
|
|---|---|
|
|
| Propose | The agent never acts silently; it always shows the plan first. |
|
|
| Approve | A human is in the loop for every action, every time. |
|
|
| Audit | Every executed action is logged and replayable from the audit trail. |
|
|
|
|
## 4. Reporting First, Writes Second
|
|
|
|
v2 ships reporting before writes because reporting is read-only and low risk. Reporting proves the pipeline end to end (propose, approve, audit) before the product is allowed to touch any system.
|
|
|
|
Low-risk write examples (tier 2, all gated):
|
|
|
|
- Draft a section of an employee handbook for an admin to review.
|
|
- Draft a reply to a customer email that a human then sends.
|
|
- Update an internal FAQ entry with an approved wording change.
|
|
|
|
Each example follows propose, approve, narrow write, audit. None of them are autonomous.
|
|
|
|
## 5. Permanent Autonomy Guardrails
|
|
|
|
These hold for v2 and every later version:
|
|
|
|
- The propose-approve-audit gate is never removed or bypassed.
|
|
- Writes are always narrow: only the approved field or record, nothing else.
|
|
- Risk tier is a hard ceiling. A channel cannot act above its assigned tier.
|
|
- Patient records and PHI remain permanently out of scope.
|
|
- Every action is logged in the messages and audit tables with the approver identity.
|
|
|
|
## 6. What v2 Does Not Do
|
|
|
|
- No free-roaming agents that act across channels or systems.
|
|
- No writes without a prior human approval.
|
|
- No patient or PHI content, regardless of tier.
|
|
- No removal of the v1 grounding and citation rails.
|