28fafce7dc
Some checks failed
Security / Security check (push) Failing after 1s
Three operator-UX gaps closed:
- Settings dialog's six-category sidebar (General / Appearance /
System AI / Integrations / Security / Maintenance) was
hardcoded English; now flows through AppLocalizations
("Allgemein" / "Darstellung" / "System-KI" / "Integrationen" /
"Sicherheit" / "Wartung"). Same for the per-panel title +
description.
- Per-channel daemon-action labels ('enable autostart' /
'disable autostart' / 'daemon restart' etc.) and the
OK / Failed result line in the toast also moved to l10n,
so the system-action feedback reads as one language.
- New 'Approvals' doc bundle (en + de) under assets/docs/,
registered as a fifth doc card on Welcome plus exposed via
the new public helper. The
Approvals, Audit and Doctor app-bars grow a Help icon button
next to Refresh that opens the matching doc in the existing
bottom-sheet reader — no extra screen, no learning curve.
Studio bumped to 0.67.0; editor path-override pulls in 0.20.1
(flow-list row polish).
Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
81 lines
2.4 KiB
Markdown
81 lines
2.4 KiB
Markdown
# Approvals
|
|
|
|
An approval is a deliberate human-in-the-loop checkpoint inside
|
|
a flow. When a step needs a human decision before it proceeds,
|
|
the flow pauses at that step until a reviewer approves or
|
|
rejects it.
|
|
|
|
## When to use one
|
|
|
|
Add an approval step before:
|
|
|
|
- writing to a system of record (cases, contracts, mailings)
|
|
- spending money (LLM tokens above a threshold, API quotas)
|
|
- destructive actions (delete, archive, send)
|
|
- anything the operator's compliance owner asked you to gate
|
|
|
|
The approval is a recorded event — every approval shows up in
|
|
the audit log with the reviewer, decision, and reason.
|
|
|
|
## How a flow declares one
|
|
|
|
```yaml
|
|
steps:
|
|
- id: classify
|
|
use: text.classify@^1
|
|
|
|
- id: review
|
|
use: system.approval@^0
|
|
with:
|
|
title: "Review the classifier output"
|
|
details: "$classify.response"
|
|
reviewer: "$inputs.reviewer"
|
|
timeout_seconds: 600
|
|
|
|
- id: write
|
|
use: erp.write@^1
|
|
with:
|
|
record: "$review.payload"
|
|
```
|
|
|
|
`system.approval` is a built-in capability — no module install
|
|
needed. It blocks the flow's run until the matching approval
|
|
record reaches a `decision` (approved / rejected) or the
|
|
configured `timeout_seconds` elapses.
|
|
|
|
## How an operator answers one
|
|
|
|
The Approvals page lists every pending approval. Click an
|
|
entry, read the title + details, decide:
|
|
|
|
- **Approve** — the flow resumes from this step with the
|
|
approval's `payload` as the step output.
|
|
- **Reject** — the flow fails at this step with the reviewer's
|
|
reason; the audit log records the rejection.
|
|
|
|
## Timeouts
|
|
|
|
If no decision arrives within `timeout_seconds`, the engine
|
|
returns `ApprovalTimedOut` and the flow fails. Set a timeout
|
|
that reflects how long a reviewer can realistically take.
|
|
|
|
## What gets logged
|
|
|
|
Every approval write hits the audit log:
|
|
|
|
- approval requested (with the title + details snapshot)
|
|
- reviewer-decision recorded (with reason on reject)
|
|
- payload + signature on accept
|
|
|
|
The hash chain catches tampering — an entry that was approved
|
|
yesterday can't be quietly flipped to rejected today without
|
|
breaking the chain.
|
|
|
|
## Architecture trade-off
|
|
|
|
Approvals are stored alongside events in the SQLite audit DB.
|
|
For higher-assurance deployments, mirror the audit DB to a
|
|
WORM sink (Compliance Gap 3, option 2). The approval contract
|
|
is the same either way — the WORM sink just makes the audit
|
|
trail tamper-evident to outside reviewers, not just to the
|
|
hub itself.
|