208 lines
5.1 KiB
Markdown
208 lines
5.1 KiB
Markdown
|
|
# OpenClaw x AtoCore V1 Proof Runbook
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
|
||
|
|
This is the concise proof and operator runbook for the final V1 policy.
|
||
|
|
It shows, in concrete paths, that:
|
||
|
|
|
||
|
|
- a Discord-originated signal cannot reach `project_state` without candidate or review gating
|
||
|
|
- Discord cannot directly execute `register-project`, `update-project`, `refresh-project`, `ingest-sources`, `promote`, or `reject` without explicit approval
|
||
|
|
|
||
|
|
## Explicit approval definition
|
||
|
|
|
||
|
|
For V1, explicit approval means:
|
||
|
|
|
||
|
|
- the human directly instructs the specific mutating action
|
||
|
|
- the instruction is in the current thread or current session
|
||
|
|
- the approval is for that exact action
|
||
|
|
- the approval is not inferred from evidence, archives, or screener output
|
||
|
|
|
||
|
|
Examples:
|
||
|
|
|
||
|
|
- "refresh p05 now"
|
||
|
|
- "register this project"
|
||
|
|
- "promote that candidate"
|
||
|
|
- "write this to project_state"
|
||
|
|
|
||
|
|
Non-examples:
|
||
|
|
|
||
|
|
- "this looks like the current answer"
|
||
|
|
- "we should probably refresh this"
|
||
|
|
- an old Discord thread saying a refresh might help
|
||
|
|
- a screener report recommending a mutation
|
||
|
|
|
||
|
|
## Proof 1 - Discord cannot directly reach project_state
|
||
|
|
|
||
|
|
Blocked path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Discord message
|
||
|
|
-> evidence
|
||
|
|
-> optional candidate
|
||
|
|
-> review
|
||
|
|
-> optional explicit curation
|
||
|
|
-> project_state
|
||
|
|
```
|
||
|
|
|
||
|
|
What is blocked:
|
||
|
|
|
||
|
|
- Discord -> project_state directly
|
||
|
|
- Discrawl archive -> project_state directly
|
||
|
|
- screener output -> project_state directly
|
||
|
|
|
||
|
|
What is allowed:
|
||
|
|
|
||
|
|
1. Discord message enters the evidence lane.
|
||
|
|
2. It may become a memory or entity candidate after screening.
|
||
|
|
3. A human reviews the candidate.
|
||
|
|
4. If the fact is truly the current trusted answer, the human may explicitly curate it into `project_state`.
|
||
|
|
|
||
|
|
Conclusion:
|
||
|
|
|
||
|
|
`project_state` is reachable only after review and explicit curation. There is no direct Discord-originated write path.
|
||
|
|
|
||
|
|
## Proof 2 - Discord cannot directly execute mutating operator actions
|
||
|
|
|
||
|
|
Blocked direct actions:
|
||
|
|
|
||
|
|
- `register-project`
|
||
|
|
- `update-project`
|
||
|
|
- `refresh-project`
|
||
|
|
- `ingest-sources`
|
||
|
|
- `promote`
|
||
|
|
- `reject`
|
||
|
|
- `project-state-set`
|
||
|
|
- `project-state-invalidate`
|
||
|
|
|
||
|
|
Blocked path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Discord message
|
||
|
|
-> evidence or operator request context
|
||
|
|
-X-> direct mutation
|
||
|
|
```
|
||
|
|
|
||
|
|
Allowed path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Discord message
|
||
|
|
-> OpenClaw recognizes requested operator action
|
||
|
|
-> explicit approval check
|
||
|
|
-> approved operator action
|
||
|
|
-> shared operator client or helper call
|
||
|
|
```
|
||
|
|
|
||
|
|
Conclusion:
|
||
|
|
|
||
|
|
Discord can request or justify a mutation, but it cannot perform it on its own.
|
||
|
|
|
||
|
|
## Proof 3 - Discrawl does not create approval
|
||
|
|
|
||
|
|
Discrawl is evidence retrieval.
|
||
|
|
It may surface:
|
||
|
|
|
||
|
|
- prior discussions
|
||
|
|
- earlier decisions
|
||
|
|
- unresolved questions
|
||
|
|
- prior suggestions to mutate state
|
||
|
|
|
||
|
|
It does not create approval for mutation.
|
||
|
|
|
||
|
|
Blocked path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Discrawl recall
|
||
|
|
-X-> refresh-project
|
||
|
|
-X-> promote
|
||
|
|
-X-> project_state write
|
||
|
|
```
|
||
|
|
|
||
|
|
Allowed path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Discrawl recall
|
||
|
|
-> evidence for human review
|
||
|
|
-> explicit approval in current thread/session if mutation is desired
|
||
|
|
-> approved operator action
|
||
|
|
```
|
||
|
|
|
||
|
|
Conclusion:
|
||
|
|
|
||
|
|
Archive recall informs review. It does not authorize writes.
|
||
|
|
|
||
|
|
## Proof 4 - Screener has no hidden mutation lane
|
||
|
|
|
||
|
|
The screener may:
|
||
|
|
|
||
|
|
- gather evidence
|
||
|
|
- classify evidence
|
||
|
|
- prepare candidates
|
||
|
|
- prepare operator queues
|
||
|
|
- report contradictions or missing context
|
||
|
|
|
||
|
|
The screener may not:
|
||
|
|
|
||
|
|
- write `project_state`
|
||
|
|
- mutate registry state
|
||
|
|
- refresh or ingest directly
|
||
|
|
- promote or reject directly
|
||
|
|
|
||
|
|
Blocked path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
screener output
|
||
|
|
-X-> hidden mutation
|
||
|
|
```
|
||
|
|
|
||
|
|
Allowed path:
|
||
|
|
|
||
|
|
```text
|
||
|
|
screener output
|
||
|
|
-> review queue or operator queue
|
||
|
|
-> explicit approval if mutation is wanted
|
||
|
|
-> approved operator action
|
||
|
|
```
|
||
|
|
|
||
|
|
Conclusion:
|
||
|
|
|
||
|
|
The screener is a filter, not a hidden writer.
|
||
|
|
|
||
|
|
## Minimal operator decision table
|
||
|
|
|
||
|
|
| Situation | Allowed next step | Blocked next step |
|
||
|
|
|---|---|---|
|
||
|
|
| Discord says "this is the current answer" | evidence, then review, then possible explicit curation | direct `project_state` write |
|
||
|
|
| Discord says "refresh p05" without direct instruction | ask for explicit approval | direct `refresh-project` |
|
||
|
|
| Discord says "refresh p05 now" | approved operator action may run | none, if approval is explicit |
|
||
|
|
| Discrawl finds an old thread asking for registration | use as review context only | direct `register-project` |
|
||
|
|
| Screener recommends promotion | ask for explicit review decision | direct `promote` |
|
||
|
|
|
||
|
|
## Practical runbook
|
||
|
|
|
||
|
|
### Case A - current-truth claim from Discord
|
||
|
|
|
||
|
|
1. Treat the message as evidence.
|
||
|
|
2. Check the canonical home.
|
||
|
|
3. If needed, prepare a candidate or review note.
|
||
|
|
4. Do not write `project_state` unless the human explicitly approves that curation step.
|
||
|
|
|
||
|
|
### Case B - requested refresh from Discord
|
||
|
|
|
||
|
|
1. Determine whether the message is a direct instruction or only discussion.
|
||
|
|
2. If not explicit, ask for approval.
|
||
|
|
3. Only perform `refresh-project` after explicit approval in the current thread or session.
|
||
|
|
|
||
|
|
### Case C - candidate promotion request
|
||
|
|
|
||
|
|
1. Candidate exists or is proposed.
|
||
|
|
2. Review the evidence and the candidate text.
|
||
|
|
3. Only perform `promote` or `reject` after explicit review decision.
|
||
|
|
|
||
|
|
## Bottom line
|
||
|
|
|
||
|
|
The V1 rule is easy to test:
|
||
|
|
|
||
|
|
If the path starts from Discord or Discrawl and ends in trusted or operator state, there must be a visible approval or review step in the middle.
|
||
|
|
|
||
|
|
If that visible step is missing, the action is not allowed.
|