Human-in-the-loop approval for AI-written code.

Governance & human-in-the-loop

Humans approve only where policy requires.

Autonomy isn't all-or-nothing. You set the policy; Ticinuum enforces it.

Agents request human approval only where policy requires it.

• Gates where they matter — a supervised ticket stops at a gate for a person to approve before it merges; when the automated loop escalates instead, the person who overrides it to merge cannot be the ticket's author or owner. A change that touches a surface your repo declares sensitive — migrations, an API or config contract, deployment — can require a human sign-off, a high-confidence critical or major finding raises a blocking gate, and an outside reviewer who requests changes on your git host holds the merge until they approve, the review is dismissed there, or a person overrides. Every gate says why it fired and where its rule lives.
• Merge on green, not on hope — the independent review gates every merge, autonomous included, and fails closed — it never passes a change it did not fully see, and a loop that stops making progress, or a review that failed, goes to a person with no merge. An approved PR then merges only once its CI checks pass — the checks your repository, git host or org requires, otherwise every check that reported; a repository with no CI waits for a person by default — and a merge conflict gets its own bounded, re-reviewed retry loop before a person is asked. Merges also wait, rather than escalate, while someone has frozen the base branch or its required checks are red, and are released one at a time, oldest approval first. A cancelled check never counts as a pass. Your git host still owns branch protection.
• “Done” means what was delivered — when the review finds a merged change covered only part of the ticket's goal, the ticket closes for what shipped and the rest is filed as its own remainder ticket — which starts nothing until someone runs it — instead of the whole thing being marked done.
• The final merge is yours until you hand it over — by default an approved, green autonomous PR waits in review, and a “Merge needed” item asks its owner to merge it with one click. Letting the agent merge on its own is a separate setting your org admin elects against a recorded disclosure; the choice lapses after 90 days unless it is re-confirmed, and it is not yet available to orgs on GitLab. A revert is always merged by a person.
• Durable human-in-the-loop — when an agent needs a person it asks — the question arrives in the app, by email and by push, and waits in your Needs-You list — then pauses, snapshots its workspace and conversation, and resumes the exact conversation and workspace under the same run ID once someone answers, surviving crashes and restarts. An unanswered question holds the work instead of letting the agent guess, unless it named a harmless default up front.
• Take the wheel anytime — operators add steering notes the next agent run follows, put a ticket on hold so nothing acts on it, postpone it until a date or another ticket with a review date so it never quietly rots, fold a duplicate into the ticket that survives, and REVIVE or CANCEL it outright.
• Plans that avoid their own collisions — when a plan breaks work into tickets, the ones predicted to touch the same files are ordered one after another instead of racing — learned from your repository's own merge history (so it needs diffs kept), with no model call. A person can remove any ordering; the paths are a prediction, not a guarantee.
• A choice not in force is never silent — a consent that lapsed, a release that changed a default you relied on, a ceiling reached, a dependency stranded — each stays in front of an admin as a standing item until a person settles it. The platform never flips your choice back for you.
• Bounded delegation — a planning or investigating agent can hand a sub-task to a persona-pinned child — inside the ticket tree's size and depth caps, its budget, and a per-tree cost ceiling; never a free-running sub-agent. On a supervised ticket the child waits for a person to promote it.
• A role-scoped kill switch — a SystemAdmin stops new work for every org at once, or for an explicit set of them from a searchable picker; an OrgAdmin stops their own. Every halt and resume is authorized server-side and written to the audit trail with an actor and a reason.
• A SystemAdmin console — retune the operational tunables — the org daily budget, the dashboard estimate knobs, the feature toggles — at runtime, no redeploy, from one guarded console that also hosts the platform-wide controls.
• A lifecycle that is machine-governed, not draggable — every ticket is born backlog and must be groomed before it can reach open; from there it moves open → in_progress → in_review → ready → done through an enforced state machine. open means “groomed and cleared to start,” ready means “validated and ready to merge” — opposite ends of the run. It is not a board you drag cards across; it is a state machine the platform enforces.

Autonomy is a dial, and your organization holds it. By default a ticket a person files is autonomous, but filing it starts nothing: once groomed it waits for a person's Run, and from that one click it runs through implementation, review and revision — gated by the budget breaker, injection quarantine, progress-bounded loops, and kill switch, not by more clicks — and then a person merges the approved, green PR with one click. Letting the agent make that merge too, and a ranked pull that starts your backlog's top work under a work-in-progress limit, are each a separate opt-in your org admin elects against a recorded disclosure; the pull also needs a platform admin to expose it. Patrols your admin schedules and the next steps of a plan a person started run without another click. Prefer an earlier checkpoint? One per-org setting makes supervised your default, and any single ticket can be set supervised, so a person promotes it, starts it, and approves it before Ticinuum merges.