rebrand Scirium docs (Wall-O -> Scirium) + add v1/v2 documentation package
This commit is contained in:
@@ -0,0 +1,62 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user