Roles and Approvals

Genesis Prover produces evidence about a change to your data estate. Evidence is only worth what its signature is worth, so the product draws one line and defends it in code: The same visibility rule applies before an approval appears in a review queue, not only when someone opens or decides it. See the API reference for Action Review inbox filtering and its incomplete-result behavior. Agent-raised Prover requests are also listed in the Action Review inbox; the API reference describes who can list them and how subject visibility filters the results. On a deployment with authentication enabled, direct Prover approvals accept a person’s interactive sign-in or that person’s own PAT; the approval record identifies a PAT signer as via personal access token. A name typed into the request is refused. An agent’s decide_approval_request call is made for the person resolved from the current conversation or the goal or mission originator, and records basis as agent_person_present or agent_delegated alongside the agent, person, conversation, goal, and turn context. The basis is the agent’s attestation; it is recorded with what the server knew about the turn. A person may approve their own proposal; package and bundle records mark this as self_approved. A view test case approval receipt records the requester id as requested_by, their display name as requested_by_label, their kind as requested_by_kind, and the bot id the request was opened under as requested_under, beside the approver’s id and label. Its self_approved flag is true when the requester’s and approver’s sign-in identities match and either the requester is a person or the request was opened under that same sign-in. So a person reviewing a request an agent opened in their Genesis conversation is not self-approving it, while an outside agent using that person’s PAT can ask and the person can approve as the requester. A decline’s sealed mirror_detail records declined_by and declined_by_id, the requester as requested_by and requested_by_id with requested_by_kind and requested_under, and declined_by_requester using the same identity rule. On a stack running with authentication off, the review doors record the caller’s claim: send X-Genesis-Signed-As to store <name> (self-reported, auth disabled), or omit it to use local operator (auth disabled). The request_test_case_approval tool is an exception: it records approval as local operator (auth disabled) without a person’s review and does not use that header. Authority-changing acts outside the review doors remain refused. The last section of this page sets out exactly which acts fall on which side. This page is written for the person on the signing side. If Action Review cannot read back a Prover settlement after approval, reconciliation is inconclusive. Its evidence says the item could not be read back and points to the server log for details; it does not expose raw driver error text. An inconclusive read-back does not confirm that the settlement was applied.

​

Approve one review bundle

An agent can now hand you one bundle for a comparison instead of separate asks for each review-queue population. A bundle may contain correspondence-rule proposals, disposition packages, and evidence-gap exception packages. The bundle is only a statement of what the agent wants you to decide; it does not change any of those records until you approve it. Read the carries counts before signing: they show how many items are included against the populations they came from. Genesis records the exact scope shown to you and refuses the approval if that scope no longer binds, rather than partially settling the comparison. The API reference describes the request, response, and authority rules for review bundles. Any signed-in person who can open the comparison can approve a bundle, including the person who proposed it; no special approval permission is required. The approval offer reflects whether the current caller has a signing identity and whether the bundle can be approved through that route. An approval of the proposer’s own bundle is recorded as self_approved. See the API reference for the reason fields and their meanings. When the bundle carries one or more disposition packages, staging also creates one composite Action Review request for the whole bundle. Review it from the linked Action Review page or card; the native bundle approval endpoint cannot apply package members. The sealed decision covers the bundle’s carried rules, packages, and evidence-gap decisions together, rather than opening separate package approvals. See the review bundle API for the response link and composite action type. To ensure the person receives only this one request, stage packages for the bundle with for_bundle=true; those packages have no individual request while they wait to be carried. If the bundle is refused, nobody has been asked to approve that package: correct the refusal and retry the bundle, or ask for approval from the package page instead. For an agent’s bundle, a pending per-package request it previously made for the same human is withdrawn and replaced by this composite request, so that human has one bundle decision to review rather than separate package asks. Requests without a conversation-thread origin cannot be adopted; they are reviewed on their own. The adopted package stays held by the bundle request: renewal cannot create a second ask while the bundle is live, and after a bundle decline or policy veto, stage a new package to request approval again. See the propose_approval_bundle guidance. An agent’s bundle containing correspondence rules alone also uses one composite Action Review request; its native bundle approval endpoint refuses the request. Human-staged rule-only bundles, mixed rule and evidence-gap bundles, and evidence-gap-only bundles keep the direct bundle approval route for the members they carry. The review surface identifies the route and whether your current identity can sign. When you reject a composite Action Review request, the bundle closes and eligible agent- or service-proposed rules it carried are withdrawn from this comparison’s queue under your reason. If you do not supply a reason, the withdrawal records a request-specific fallback. The rule definitions remain proposed: another comparison is unaffected, and proposing the rule again on this comparison makes it visible again. A rule already ratified or still held by other open review work is not withdrawn. While a rule remains withdrawn here, its approval request is not offered and it cannot be approved; propose it again to restore it to this comparison’s queue. A refusal explains in plain language whether the rule was declined in Action Review or otherwise withdrawn, and who withdrew it. Its comparison-scoped rule dossier includes the reason, grounds, and withdrawal time. If a bundle is retracted or superseded by a replacement, its still-open linked Action Review request is ended so it leaves the reviewer’s queue. While a composite Action Review request is live, it holds the correspondence rules it carries for that decision. A separate rule sign-off cannot change one under the request, and another bundle cannot approve a rule already held by a different live request; that approval is refused without settling its other members. Decide the owning request in Action Review first. For the agent tool’s bundle-composition refusal when Action Review-only rules are combined with evidence gaps, see the propose_approval_bundle guidance. The composite Action Review request states in plain language what approval does. For a data-derived or unclassified rule, its dossier explains why the rule is not a suggested default and shows who proposed it, whether edge-fixture qualification passed, its field-survival tier and the first 12 characters of its evidence fingerprint, its declared boundary, and the estate-pair fingerprint. Approval re-qualifies the rule against that pair before ratifying it. The dossier also lists each rule being ratified and each evidence-gap group receiving exceptions. For each disposition package, it lists every promotion and up to 20 other items individually, including the disposition and durability; remaining non-promotion items are counted by disposition and durability. Each evidence-gap group names up to 20 members and counts any remaining members. The linked request applies all of its carried members in one transaction or none. When the proposer supplied a brief, the request leads with its title, proposal, reason, and points to weigh; the full rationale and sealed decision remain available in the details. The request attributes the reason and weighing points to the proposer, not to the reviewer, and makes no recommendation. For each individually stated package finding, it names the table and column recorded for that finding when the ledger can verify its key; otherwise it says why it cannot identify the scope. It also calls out any carried waiver that lasts more than a year. Declining closes the bundle without applying any member; if it carries rules, eligible agent- or service-proposed rules are withdrawn from this comparison unless already ratified or still held by other open review work. For new requests, a ratified-rule line without attached evidence names the component pair and license boundary. A column-scoped rule names the exact object and column it licenses; an object-scoped rule names only the object. A rule with no declared boundary says it is not limited to specific columns and that its own conditions still decide where it applies. An unreadable declared boundary says the rule licenses nothing. Requests already sealed with explanation version 1 keep their earlier wording.

​

Action Review also reviews promoted rules

When an Action Review decision approves a carried correspondence rule or promotes a rule from a disposition package, that same decision records the rule as reviewed. It is marked confirmed and tied to the Action Review request, so the reviewer is not asked to confirm the rule separately. The review timestamp is the sealed decision time when available, otherwise the approval time. Some correspondence rules are intentionally excluded before they reach this one-click ceremony. Their excluded_rules entry gives the specific reason and the propose_approval_bundle guidance describes the separate review path for those proposals.

​

What lands in front of you

You do not go looking for work. The Prover workspace in the Genesis sidebar collects it: Opening one takes you into that comparison’s Human Review workspace, which is organised as the argument you are being asked to accept: Overview, Requirements (what the specification asked for), Findings (what was measured), Correspondence (proposals waiting on you), Licenses & references (what has already been accepted, and on whose authority), Runs, Coverage and Audit. For platform rules, Correspondence also shows the recorded boundary-test results in their qualification. The correspondence-rules API reference defines the qualification’s failure counts. The estate as a whole carries the standing surfaces: Ratifications, Court, Conventions, Governance, Attestations and Migration validations.

​

What you are attesting to when you press a button

Each act means something specific and durable. This is the part worth reading before your first review.

​

Record the review decision

The run-level sign-off for a whole comparison. A person may record it directly or ask an agent to record it for them; either way, the approval rests on that person. Three values: Two properties surprise people the first time:

• Resetting is as much a decision as approving. Moving a comparison back to awaiting review needs the same authority as approving it, because it is equally a statement about the run.
• The decision is checked against the population it was made about. An approval is recorded against a complete population with no unresolved blockers, and it is withdrawn if that population later moves. An approval cannot silently come to cover findings that did not exist when you gave it. Legacy comparisons use the same standing check on the Human Review and comparison-card surfaces; see the comparison rollup behavior.
• authority is an attribution note, not authorization. An API caller may include free text stating who authorised the decision. Genesis records it beside the server-derived reviewer identity; it never replaces that identity or grants the permission to record the verdict. Resetting to awaiting review cannot carry the note because that state records no decision. For an agent decision, the required approval_basis is a separate attestation recorded with the approval; it does not replace authority.

​

Approve test cases for a view

An agent can ask for the test cases used to prove a view to be approved in Action Review. The request covers the cases currently in effect for one view. The Prover groups case sets by the last dot-separated part of target_node, matching how a run groups its cases, so every group for that view is covered by the approval. A Prover behavior run (validate_migration, run_trajectory_campaign, or qualify_stimulus_campaign) uses only test cases a person approved here. All three runners enforce this gate before injecting cases; see the validate_migration reference for its exact refusal conditions. Asking needs view_connections and a signed-in person; any signed-in person whose access covers the request’s full review scope can approve it, without a special permission. The Action Review API reference explains how that scope determines which Prover requests are visible. With sign-in off, test cases are approved at once when the agent asks, and are marked as not reviewed by a person. For requests on a pair prepared with prepare_migration_prover, Details lists each source and target profile the approval covers, with the profile facts recorded when the request was asked. When it covers multiple prepared profiles on either side, the Decision tab says so and points to Details. For how Action Review handles legacy requests whose prepared pair is no longer recorded, see the Action Review API reference. The Decision tab summarizes what you are deciding: each case’s name and row count, the first sentence of its rationale, whether it changed since approval, was previously declined, had an approval withdrawn, or is already approved, and the stored SQL condition. Details show the complete test-case content the approval binds to: every inserted row, the full rationale and tags, how a run reads the view’s output, and—after a decline—who declined, why, and exactly what differs now. Review those details before approving. Approval records the cases under your name and carries forward to later runs while those cases remain unchanged. The decision brief adds a line about the situations Prover can list from the view’s stored SQL. When space permits, it gives the situation and claimed counts and the most important one no case claims; if the tab is tight on space, it points to Details instead. Details lists the unclaimed situations in plain words with their coverage: tags; when Prover can read a distinct rewrite mapped to the view, its situations are included too. A case claims a situation only when its tags name it in the stored SQL text; that claim is the agent’s statement, not a result checked by running the case. Without coverage tags, every situation is shown as unclaimed. For how agents get and apply these tags, see logic-path coverage claims. When a condition is wholly an OR and every alternative is listed, Prover treats it according to what the condition does. A CASE rule is shown through its alternatives, and left out of the situation counts, only when its default is listed too; an unclaimed alternative then appears on its own, while a claim on the rule itself adds nothing to the count. A filter or output column made wholly of listed alternatives remains its own situation: it describes what happens when none of them holds, so it needs its own claim tag. If an alternative is not listed, or the OR is under an AND or NOT, the condition remains its own situation. The brief’s example prefers an unclaimed situation that does not merely sum up alternatives when one is available. Prover reads the newest scan of the request’s boundary; if that scan holds no such view, it reads the newest matching view among the 50 most recent scans. If no stored text can be read, the request says the situations could not be listed and still proceeds. Details can name up to 50 situations; conversions are counted but not listed, and the list may note when the SQL contains situations it could not describe. A large view may be split into multiple requests, each containing whole test cases. Each approval covers only the cases in that request; the view is fully approved only after every request is approved. If a case is edited, added or withdrawn while a request is waiting, its request is withdrawn rather than applying to different content. Declining approves nothing, and the same unchanged cases are not asked about again; the agent must revise them to address your reason before asking again. For the tool’s inputs and response, see request_test_case_approval.

​

False alarm (Prover)

instrument_defect is labeled False alarm (Prover). Use it when the Prover, not the build or its specification, misread a difference. It returns the finding to the caller, charges neither artifact, and resolves the finding without approving a change. Genesis also files a Prover defect report. Findings in one ruling act are reported once per pattern; later findings join that pattern’s open report. A report discarded as filed in error is no longer open, so a later finding of the same pattern starts a new report. The ruling is recorded even if report filing fails. Its filing status is delivered when Genesis was notified, user_action_required when a report exists but must be sent using the prepared email, or failed when no report could be filed. The finding’s filing details are available from the findings dispositions API.

​

Approve a one-time exception

This particular finding, this once, is accepted. It does not create a rule and it does not cover the next occurrence. Recording a different diagnosis for that finding afterwards retracts the exception — you approved something about the old answer, so the approval does not survive the answer changing.

​

Ratify a correspondence rule

This class of difference between the two platforms is licensed for this transition, until the rule is retired. This is the heaviest button on the surface, because a rule licenses differences you have not looked at individually — including future ones. What protects you: a rule only reaches you after it is scoped to specific measurement classes and qualified against edge cases it must accept and edge cases it must reject; a proposal never licenses anything by itself; and a rule later refuted is retired rather than quietly downgraded, so the history stays readable. The Ratifications worklist shows the proposer recorded on the rule. If an existing content-addressed rename is declared again, that recorded proposer remains attached to the proposal rather than being replaced by the latest caller. For a data-derived rule in a newly proposed disposition bundle, the signed evidence uses the proposing agent’s display name when one was recorded, or its bot id otherwise. The bundle seals the name as proposed, so a later name becoming available does not change its signed evidence; bundles proposed by older clients retain their original evidence without an agent name. The rule’s sign_off_route distinguishes direct sign-off from Action Review. Any rule proposed by an agent or service, including a data-derived or unclassified rule, is signed off only through Action Review; a person’s own rule stays on the direct route. Use the rule’s approval request action to create or reuse a one-rule Action Review request. An open agent- or service-staged disposition package is approved through its own request. A person’s open package cannot ratify an agent’s or service’s rule: request approval for the rule first, then approve the package. The Ratifications worklist presents a signed-in person as eligible to sign when the rule’s route permits it; Prover rule approvals require no special permission. See the API reference for the returned signer-eligibility fields. The API reference explains which promoted rules an open package claims and the related refusal codes. A same-cause cluster can be proposed as one reusable ruling question. The Prover keeps each member’s single-column licensing boundary, groups members that share the same mechanism, and records the proposing reviewer as owner of any member that was unowned. If the members do not derive one reusable rule, or a member derives a rule that was already rejected, the proposal is refused as a whole rather than partially written; proposing a rejected rule again cannot revive it.

​

Ratify a delta

This is what the change was meant to change — a rename, a relocation, an object introduced or retired, a repair, a derivation. The empty delta is meaningful and ratifiable too: it says this transition intends to change nothing.

​

Waive a finding

Stop this finding gating attestation. Every other diagnosis verb is an agent’s to record. This one is not, because it is the one that stops a finding counting. A new waiver is an exception with a named owner and expiry; its terms appear in the Waivers ledger. Some older waivers predate recorded terms. Once a waiver’s recorded expiry passes, it no longer licenses the finding.

​

Approve a disposition package

An agent has staged a set of diagnoses for a comparison’s findings, with its evidence attached, and applied none of them. Staging creates one Action Review item of type prover.approve_disposition_package.v1 for that package generation. The package is attributed to the acting agent, not the person whose thread it served; the person is recorded as the agent’s on-behalf-of principal. If no bot id was available, the proposer is shown as agent (unattributed). The package approval page shows any cited clarification and its provenance label beside the item. A citation may support a defect over the seat’s open question or record the owner’s ruling on a promote_delta or waived item; for the requirements, see the tool guidance. For a newly staged waived item, the page presents the waiver owner and expiry the reviewer is approving; the expiry must still be in the future at approval. Older packages staged before terms were required may have no recorded expiry. The approval panel explains in plain language what the package approval would do and why a proposed promotion cannot be approved when its rule fails review. Review the stated impact before using the single Approve action; it applies the eligible package items together, not as separate item approvals. The package read carries the promotion previews with the package, so the panel loads the proposed rules and any refusal without a separate preview request. Any signed-in person who can open the comparison can approve or decline the package exactly as staged, as a whole, from the package’s own Prover approval page. Nobody can edit, drop or re-diagnose an item on an agent’s package. Approval applies the items the approval can license; if any item is wrong, decline the package so the agent can stage a corrected one. The page uses the linked Action Review item as its approval record; it is not necessary to send the person to the generic Action Review inbox. The package’s proposer may approve their own proposal; the approval record marks it self_approved. A person’s own PAT also signs for its owner. See the package approval API reference for the approval fields and response codes. Initial package approvals use set-based writes rather than one write per item; see the package approval API reference for batching details. On Snowflake metadata databases, the opt-in estatechar hybrid-table setting can reduce keyed-write time; see Estatechar store settings. For the approve response timing and where a False alarm (Prover) filing status appears, see the package approval API reference. For a directly approvable package, Approve now returns as soon as the decision is accepted, while Genesis records the rulings. The package shows the run as accepted, applying, then done when every selected ruling is recorded; if it stops, the failed run explains which items were not recorded and whether they can be retried. Check the package again for its latest progress; an item counts as signed only after its ruling appears in the package record. The approval-runs API documents the progress and retry fields, including what to do when the server cannot confirm whether an attempted decision was recorded. Promotions that fail the approval preflight are refused at staging, not sent to the person for approval. If a decision later leaves only promotions nobody can approve, those items are returned to the proposer and the package closes rather than asking another person to review them; see the tool guidance. The approval projection is content-bound: if the package, its evidence identity, or a rule a promotion would license changes, the item is refused and appears as approval drift; the agent must stage a fresh package. This includes a staged rule whose stored definition hashes to a different id: it is not previewed as the named rule. A promote_pi or promote_delta promotion carries its stated durability, from this comparison to the relevant standing boundary; the package records the widest durability it asks for. The reviewer-visible durability levels are: A target_defect send-back is not a package decision: the agent applies it directly, and the finding remains open until a fresh comparison verifies the fix. If it touches an item in an open package, that package’s item becomes stale and cannot be approved against the changed finding. See the send-back tool reference. At startup, Genesis also applies eligible target_defect items left undecided in open initial packages staged before send-backs stopped requiring approval. It applies them under the original proposer, without a person’s signature; corrective-package items, items that are moved or already diagnosed differently, and items still answering an Adjudicator question without a cited clarification remain for a person. A package with no remaining items to approve closes. This startup handling is idempotent. The package’s durability is the furthest-reaching level among its items. The Action Review receipt links the proposal and digest back to the Prover’s decision event. This approval lifecycle, including staging rules and approving rule promotions, is supported on Snowflake ledgers as well as the other supported ledger substrates. The workflow checks rule qualification and promotion refusals before writing; if the store changes between a check and its write, the Snowflake transaction rolls back as a whole. See the disposition package tool documentation for Snowflake retry, claim, and failure behavior. On Snowflake, new promoted rules are written in one batch, so large approvals that create standing rules can finish up to 10 seconds sooner. The approval checks and all-or-nothing transaction behavior are unchanged. The package’s open decision also appears as one decision card beside the agent’s answer in chat. A package card reads the linked Action Review request before offering an action; if that request is declined, policy-denied, applied, withdrawn, or still being checked, the card reports that request state instead of treating the package listing as authoritative. A pending request’s chat card is delivered once: by the call that opened it, or, if that call could not send the card, by a later call that finds the request still pending. The ledger prevents later replays from sending a duplicate. A policy-denied request also closes its package generation. For the tool’s Action Review package-request behavior, see the disposition package tool guidance. The package read and the chat card use the same server-side eligibility verdict. For the response fields, reason values, and the native direct-decline exception for agent- and service-staged packages, see the disposition package API reference. This keeps a proxy-provider session’s card and package page aligned. If a person declines the linked Action Review request, the package closes as retracted and releases the comparison, so the agent can stage a new package rather than asking for the old generation again. A package an agent or service staged is never decided item by item; item-by-item decisions on the direct route are for a person’s own package, and policy denial of such a request also closes the generation. Package reads record retracted_as: "declined_in_action_review" or "policy_denied_in_action_review" and retain any item rulings already made. The sealed Action Review mirror also records closed_before_ruling; it is true when the package was already closed before the ruling was sealed, so the decline is not credited with closing it. The package page offers Withdraw my signature for item signatures eligible to the current reviewer; see the package-read API response for the caller’s withdrawable keys and possible refusals. Unsigning reopens the package generation and retires its linked Action Review item, so a later approval is a new ask.

​

Settle, ratify or unsettle a ruling

A ruling fixes a direction for a whole class of ambiguity within a named jurisdiction, so subsequent work resolves the same way without asking again. Unsettling is never a delete: the slot reverts and the record keeps the superseded direction reconstructable.

​

Approve or decline a consult ruling

The Consult agent has ruled on one named ambiguity. Approving accepts the ruling and seeds and ratifies its direction in one action. Declining refuses it — and in the mode where the ruling was applied provisionally, withdraws what it applied. Where you decide depends on who asked for the ruling:

• An agent or a service asked — the usual case, and also any ruling recorded before the requester was — the finding shows Ask for approval instead of Approve and Decline. Pressing it opens one Action Review request for that exact ruling; any signed-in person who can read the finding, including the person who requested it, can approve or decline it there. Pressing again shows the request already asking. The finding’s own Approve and Decline refuse such a ruling (409 consult_requires_action_review).
• A person asked — the finding keeps its own Approve and Decline.

A declined request closes the ruling: it is recorded as declined with the reason given, and asking again is refused. To revisit the finding, ask Consult for a new ruling. For a Prover Consult request raised through POST /api/tool_call, Action Review’s Asked by label uses the optional caller_name when supplied, after the caller’s outside agent (sign-in <first 8 characters of the id>) label; without a name, only that label appears (unknown if the id is unavailable). The name does not change who is authorized. See Call Tools Without a Chat Thread for the request field. While such a ruling waits on its request, the provisional direction it seeded is also decided there: the ruling library’s Confirm and Change point to the request instead. Once the finding has been ruled on again, that older direction can be confirmed or withdrawn directly in the ruling library.

​

Decide a court docket, or an improvement docket item

A court docket is a prepared case: the neutral question with both readings verbatim, representative instances with side-by-side values, the full instance list, the aggregate and maximum materiality, and every agent’s recorded reasoning. An improvement docket item is the other direction — a proposal that the instrument is what should change. Accepting an improvement licenses the deviation for every later proceeding, so an improvement an agent raised is accepted through Action Review: ask for approval on the entry, and one request covers every open element of its finding. When an agent files an improvement, Prover attempts to open that request automatically; the filing result reports whether it opened. If automatic opening fails, the entry remains filed and a person can ask for approval. Rejecting stays a direct act. Declining the Action Review request is not a rejection — the elements stay open and unlicensed, and a person can ask for approval again. Accepting grants a waiver, so the approval must name a future expiry and who answers for the waiver. A person’s request can set waiver_expires_at and optionally waiver_owner; when the request omits terms, it uses usable terms the filing agent proposed. The owner defaults to the person who asks when they name an expiry. The waiver allows the finding only until that expiry. For new requests, the Action Review explanation names the data covered by the finding and its licence: the table and column, plus any scoped index, constraint, obligation, row, or target image, along with the component pair and comparison. If the request will install no licence, the explanation says so. If the diff-ledger coordinates do not reproduce the finding key, it says the covered data cannot be identified rather than guessing. Requests made before this explanation was added retain their earlier wording.

​

One thing a diagnosis never does

Diagnosing a finding does not close it. Deciding that a difference is a target defect, or licensing it, or waiving it, records what you concluded — but the finding discharges only when a later comparison over the same pair no longer exhibits the difference. Closure is always independent re-verification, never assertion. Nobody, including you, can close a finding by saying so.

​

Who can approve

Prover approval decisions need a named person, not a special reviewer permission. The person who proposed the item may approve it too. With authentication enabled, the person can use their own sign-in or PAT; an agent can also decide an eligible Prover Action Review request for them when they ask in chat or when the decision is part of a goal, Blueprint, or mission they set. The approval record identifies both agent and person and carries the stated basis and server-observed turn context. A PAT approval is attributed to its owner and labelled via personal access token; an MCP client using that person’s PAT has the same attribution. A call authenticated only as an agent cannot approve; neither can the system identity or an app-only token. Other Prover authority-changing acts remain separately permission-gated; see the RBAC Practical Guide.

​

When an agent can decide a Prover request

An agent can decide a Prover Action Review request with decide_approval_request only for the person in the conversation or the originator of the goal or mission it is carrying out, and only when the person asked or delegated that decision. The person must be able to see the request’s subject. The tool records the agent, the person, and whether the person asked in chat (agent_person_present) or delegated the work (agent_delegated). Other Action Review requests are still for a person to decide; the tool refuses them and directs the user to the review page.

​

What agents do

Everything that is not signing — which is most of the work, and the reason this division exists at all: For how staged disposition packages are reviewed and what agents should put in reviewer-facing package text, see the disposition package tool. If a governed tool hits an unexpected fault before an action is created, it reports that the action was not proposed and directs operators to the server log instead of returning raw driver error text. If Action Review inserted a request but could not read it back, the response names the request when its ID is known and leaves its state unknown; read the request before acting on it. A fault while checking an existing request is reported as a fault, not as a retryable outage. Deliberate preparation refusals, such as invalid arguments or a connection policy refusal, retain a reason the agent can correct. Every review write is appended to a log rather than overwriting one, which buys three things: each decision names its author and its moment; two reviewers working the same comparison never silently lose each other’s writes; and the current state is a pure reading of the log, so a display bug is never a data-loss event.

​

On a stack with authentication turned off

Local and evaluation stacks commonly run with authentication disabled. With auth off every caller reads as the administrator, so a permission check proves nothing about who is asking. Genesis therefore splits the behaviour rather than pretending otherwise: An agent’s Prover approval on an authentication-disabled stack is recorded as local operator (auth disabled) and still carries the approval basis and agent context. The basis is required, but there is no verified person identity on that stack. On a stack with authentication off and no X-Genesis-Signed-As claim, disposition packages approved through Action Review appear in Packages I’ve signed; see the signed-package API listing for how it matches those decisions. The attribution is deliberately self-describing so a later reader can tell a verified human from an auth-off local write from the stored label alone. The header is a claim, not a credential; Genesis does not verify the name. The audit log never overstates the strength of an identity. With authentication enabled, Prover approvals still rest on a person. A person may decide directly or ask an agent to decide an eligible Prover Action Review request. A call authenticated only as an agent cannot approve; neither can the system identity or app-only machine tokens. Prover approval doors accept the person’s own PAT; direct API and authority routes continue to reject delegated credentials.

​

Next

• Overview — what the Prover measures and how its six components fit together.
• How a run works — statuses, provenance, and where to watch.
• RBAC in Genesis — how roles and permissions are administered across the product.