Concepts
Core concepts
The mental model behind Asenta: the loop, the gate, policies, and the learning loop.
The Asenta loop
Every item in Asenta moves through the same six-phase loop:
- 1
Connect
Create an API key in the dashboard. Attach it to an approval policy if you need multi-step sign-off. Configure the oversight gate (or leave defaults: every item goes to review).
- 2
Send
Your AI pipeline POSTs the output to /api/queue with your API key header. Include content, an optional confidence score, segment tag, and per-item webhook URLs.
- 3
Review
The oversight gate runs synchronously at intake. If the item needs a human, it lands in the queue as pending and reviewers are notified. If the gate clears it, it auto-fires immediately.
- 4
Decide
A reviewer opens the item, sees a side-by-side view (rendered AI output vs editable WYSIWYG), and chooses: Approve, Approve with edits, Reject, or Regenerate. Edits are saved as the content-of-record.
- 5
Fire
Once the approval policy is satisfied (e.g., quorum reached), Asenta fires your on_approve or on_reject webhook with the final content and an HMAC signature. At-least-once delivery with 3 retries.
- 6
Learn
If the reviewer edited the content, Asenta stores the original/edited pair. Promote pairs to style rules in the Quality screen; your pipeline reads them from /api/feedback to tighten future generations.
The oversight gate
The oversight gate runs at intake (before any human sees the item) and makes a single binary decision: review or auto-fire. It is evaluated in strict precedence order — the first matching rule wins.
Fail-closed
Any rule evaluation error, missing operand, type mismatch, or unrecognised operator sends the item to review. The gate never silently skips to auto-fire on an error.| Priority | Condition | Decision | Notes |
|---|---|---|---|
| 1 | compliance_mode = true | Always review | Highest priority. Cannot be bypassed by any rule. |
| 2 | audit_mode = true | Auto-fire (approved) | Skip review entirely. Useful for pipeline end-to-end testing. |
| 3 | always_review_rules match | Always review | User-defined field/op/value conditions that force review. |
| 4 | confidence < threshold (or missing) | Always review | Confidence is demote-only — it can never promote an item to auto-fire. |
| 5 | auto_bypass_rules match | Auto-fire | User-defined conditions where the item is safe to auto-fire. |
| 6 | sample_rate roll | Review or auto | Random % of remaining items go to review. Rest auto-fire. |
| 7 | (default) | Always review | Fail-closed: anything not explicitly cleared goes to a human. |
always_review_rules and auto_bypass_rules are arrays of deterministic conditions you define per API key. Each condition is a { field, op, value } triple evaluated against the item's metadata.*, segment, confidence, or value (a numeric field read from metadata.value — useful for amount/price thresholds with the lt/gt operators). No eval, no regex — purely deterministic comparisons.
Example: { "field": "segment", "op": "eq", "value": "EU" } in always_review_rules forces every EU-segment item to review regardless of confidence.
Approval policies
An approval policy is a multi-step sign-off requirement you attach to an API key. It specifies how many reviewers must approve, and in what order.
Any
The first reviewer to approve satisfies the policy. Fastest path to approval.
All
Every participant listed must approve. Veto power: a single reject terminates the item.
Sequential
Participants are notified and must approve in order. Each step unlocks the next.
Quorum (n of m)
n out of m listed participants must approve. If the remainder can no longer reach quorum, the policy resolves as rejected.
Timebox: Each API key can have an approval_timeout_minutes value. If the item is not decided in time, the configured on_timeout_action fires: expire, escalate_expire, or auto_approve.
The learning loop
Asenta is not just a gate — it is a preference capture system. Every time a reviewer edits an item before approving, Asenta stores the original AI output alongside the human-edited version as an edit pair.
- 1Reviewer edits content and approves. Asenta saves original_content alongside the approved content.
- 2The Quality screen surfaces these pairs. You inspect them and click "Promote to rule" on patterns worth generalising.
- 3The promoted rule appears in style_rules, associated with the item's segment.
- 4Your generation pipeline calls GET /api/feedback (optionally filtered by ?segment=) to pull the latest rules and example pairs.
- 5Inject the rules into your system prompt. Edit rate drops over time as the model learns your preferences.
Asenta does not own generation
Asenta captures edits and serves rules — it does not call any language model. Your pipeline is responsible for generation; Asenta closes the quality loop by giving your pipeline its own edit history as structured feedback.