.webp&w=64&q=75&dpl=dpl_CpQbZ7uW7SJY3tWJBtJsf3EBnJyp){kind=small}
SigillumCanonical seven-stage flow
Policy decisions should stay attached to the existing quote -> 402 -> inspect lifecycle, not invent a second control path outside persisted actions.
POLICY CONFIG
Maintainer controls
Policy Config
This surface translates Sigillum’s current policy direction into an operator-facing control board. It does not mutate live rules yet, but it now shows the exact controls maintainers and agent operators need for production readiness.
Maintainer surface
What this page owns today
These cards translate the live Sigillum product state into a maintainer/admin runbook without exposing raw payloads or editing the payment path.
Threshold controls
Maintainers need explicit controls for fail-on-warn, recommendation gating, and optional score ceilings before Sigillum can be treated as a mature branch or workflow gate.
Budget-first policies
Policies should also explain when to pause before spend. Quotes already provide the truth source, so budget-based blocks can sit alongside risk-based blocks.
Primary runbook
Policy model to finish next
These are the concrete control layers that turn Sigillum from a proof feed into a real operator gate while still respecting the current hosted architecture.
Risk outcome gates
The first layer should let an operator decide which Sigillum outcomes are acceptable for their repo or agent flow.
- Allow `pass` only for strict repos.
- Allow `warn` with optional fail-on-warn control for softer rollout.
- Always block explicit `block` recommendations.
Score-based ceilings
Some teams will prefer a numeric ceiling rather than only a recommendation gate. That should stay additive rather than replacing the recommendation signal.
- Set a max `Sigillum Risk Score` for merge or deploy approval.
- Treat missing scores as policy-visible rather than silently ignored.
- Show the exact threshold that triggered the block in receipts and summaries.
Budget and spend guardrails
Quotes already expose the price before inspection, which makes spend policy a natural companion to risk policy.
- Max spend per action keeps one inspection from surprising a team.
- Daily and monthly caps help maintainers and agents stay inside budget.
- A budget block should be persisted and readable just like a risk block.
Admin checks
Controls this page should eventually drive
These cards define the production-ready policy contract without widening into server edits in this worker.
GateRecommendation thresholds should be explicit: allow pass, allow warn, or block warn and block outcomes by default.
ScoreA max risk-score threshold is still missing from the real UI and action surface, even though maintainers will expect it once they start using branch protection seriously.
BudgetBudget ceilings belong in the same policy family as risk thresholds because the quote already tells the operator the expected spend before inspection.
AuditEvery policy-triggered stop should explain whether the reason was recommendation, score, or budget so teams can trust why Sigillum paused the action.
Admin metrics
What maintainers should watch
These are the operational proof points the current GitHub, policy, and pricing surfaces should make easy to audit before expanding scope.
Repo default
Warn can pass
That is a safe initial state for adoption, but production repos typically want stronger enforcement once the workflow is trusted.
Recommended knobs
4 core gates
Recommendation threshold, max risk score, spend cap, and comment/reporting mode are the smallest serious maintainer control set.
Shared logic
One policy core
GitHub maintainers, indie builders, and autonomous agents should all consume the same rule semantics even if their UI differs.
Audit requirement
Why blocked?
Whenever a quote or receipt is blocked by policy, the reason should be clear and persisted so teams can audit why Sigillum stopped the action.
Pricing packaging
Persona-facing commercial framing
One quote engine still prices the work. These cards show how that same logic can be presented to different operators without introducing separate backend math.
Maintainer policy
Per PR + repo cap
Best for review workflows where the admin wants a monthly ceiling and deterministic branch-gate behavior without introducing subscription billing yet.
Indie builder policy
Per inspect + personal cap
Best for hosted CLI use, where a solo user wants a simple spend ceiling and a clean answer before paying for inspection.
Agent policy
Per action + team budget
Best for automated systems where multiple runners or agents need budget guardrails before unattended spend accumulates.
Useful links
Stay inside persisted proof
These routes let maintainers move from runbook guidance back into live proof without hunting through internal docs.