Admin playbook

How to change who and what holds authority in a DISCINTEL Business workspace, safely and on the record.

Updated October 21, 2026 · Early access · For the sample institution, ACME Financial Services

What changed on 21 October: a new play, Record an agent revalidation, and three routine checks: open handoffs, Legal Intelligence reviews and the age of the regulatory snapshot.

What changed on 15 October: links to the guided tours that show administrative changes on real screens, beneath the principle below.

What changed on 14 October: the one-open-change rule now covers domains, and its lock ends when a change is executed, blocked, withdrawn or rejected; the change in progress row in troubleshooting now says to finish, withdraw or reject the open change.

Three guided tours show administrative changes on real screens, from proposal to read-back: roles, retention and break-glass, environments and jurisdiction control.

1. Rules that always apply

• You can't approve your own request. The requester is excluded from every approval, and for role changes so is the person whose role changes.
• You can't change your own standing roles. Assign and Remove role are blocked when you are the target. Break-glass is the one exception, because it is temporary and needs two approvers.
• Segregation of duties is enforced. One person may not hold both roles in a pair: Treasury Manager and Payment Releaser; Payment Releaser and Payment Preparer; Security Administrator and Break-Glass Approver.
• One open change per target. While a change to an agent, tool, role, domain or policy is pending, its row shows change in progress and no second change can start. The lock ends when the change is executed, blocked, withdrawn or rejected, and the button comes back.
• Only certain roles may request changes. The control plane accepts requests from the Security Administrator and the Treasury Manager. You act as Olivia Carter, Treasury Manager.
• Admissions are single-use and short-lived. An execution admission works once and expires after five minutes.

2. Every change, step by step

All plays below follow the same path. Each step changes nothing until the last one.

1. Open Administration in the left menu and choose the change's button. A form opens.
2. Fill it in and pick a Reason: ACCESS_REVIEW, JOINER_MOVER_LEAVER, SECURITY_INCIDENT, MODEL_REVALIDATION, POLICY_CHANGE or REGULATORY_REQUIREMENT. Choose the form's Propose … button. You land in Chat with a proposed action. Nothing has changed yet.
3. On the action card, choose Submit for governance evaluation. The server returns the decision with every check. Administrative changes need approval, so expect ASK; a failed check gives BLOCK, missing information gives HOLD.
4. Open the Approvals tab and choose Record approval for each pending approver. In the sample, approvers are simulated and named on the button. An approver can instead reject or send back the change. Each pending approval shows when it lapses (72 hours unless the obligation sets approval_ttl_hours); a lapsed approval can't be signed or used, and the change must be evaluated again.
5. Open the Execution tab and choose Request execution admission. This is the step that makes the change. The server re-checks the decision, approvals and tool, issues a single-use admission, and the control plane applies the change.
6. Check the result. The Outcomes tab shows the record re-read after the change (for example, re-read from the record layer: PRODUCTION, TEST). The Execution tab shows Closure · CLOSED · server-evaluated. If it shows not yet evaluated, choose Evaluate closure obligations.

3. Who approves what

4. Plays

Assign a role

Where: Administration → Principals and roles → Assign role. Form: Principal, Role, Reason → Propose role assignment.

Blocked when the target is you, the target or role is inactive, the person already holds the role, or the role conflicts with one they hold (segregation of duties). The decision names the conflicting role.

Remove a role

Where: Administration → Principals and roles → Remove role. Form: Principal, Role, Reason → Propose role removal.

Blocked when the target is you, the person doesn't hold the role, or removing it would leave an approval obligation without enough eligible approvers once the requester is excluded. The decision lists each affected obligation and the count that remains.

Break-glass access

Use only for an emergency where standing access isn't enough. Where: Administration → Break-glass access. Form: Principal, Role, Duration (5 to 240 minutes, default 60), Emergency justification → Propose break-glass access.

• A justification under 20 characters is held for a documented reason. Write what is happening and why standing access isn't enough.
• Over 240 minutes is blocked. Segregation-of-duties conflicts are blocked.
• The role expires on its own at the end of the window; the app checks every 30 seconds and records the expiry as evidence. Active grants show under Temporary (break-glass) with their end time.

Suspend or reinstate an agent

Where: Administration → Agents → Suspend (or Reinstate for a suspended agent). Form: Reason → Propose suspension or Propose reinstatement.

• The decision tells you how many of the agent's open actions will need re-authorization.
• On execution the agent is suspended at once: its open decisions are superseded, approvals and admissions invalidated, and its open actions move to re-authorization required. A suspended agent can't be selected.
• Reinstating lifts the suspension. Actions invalidated by the suspension stay invalidated; they must be re-evaluated.

Change an agent's environments

Where: Administration → Agents → Environments. Form: tick Production and/or Test, Reason → Propose environment change.

• The button stays disabled until the selection differs from the agent's current environments, and while nothing is ticked.
• Removing Production takes the agent out of live use. A red panel appears and you must tick I confirm … should be removed from Production. The server holds any request that removes Production without that confirmation, and a confirmed one shows a ⚠ warning on the decision.
• Removing an environment sends the agent's open actions there back for re-authorization. The decision tells you how many.
• Agents start registered for Production only. To let an agent act in Test, add Test with this play.

Change a domain's jurisdictions

Where: Administration → Governance domains → Jurisdictions. Form: tick the jurisdictions (US, EU, UK, CN), Reason → Propose jurisdiction change.

• A payment, claim or purchase order is blocked unless both its tool and its governance domain allow the jurisdiction where it takes effect. This play changes the domain and all of its business tools together, so they always agree.
• The button stays disabled until the selection differs from the domain's current jurisdictions, and while nothing is ticked.
• Removing a jurisdiction blocks the domain's actions there. A red panel appears and you must tick I confirm the removal; the server holds a removal without it. Open actions there go back for re-authorization, and the decision tells you how many.
• A jurisdiction outside the institution's registered jurisdictions shows a ⚠ warning on the decision. The institution record itself is not changed by this play.
• Domains start with US only. Administrative actions are not jurisdiction-checked.

Disable or re-enable a tool

Where: Tools & Integrations → the tool's Open → choose a reason → Request disable (governed), or Request re-enable (governed) for a disabled tool.

On execution a disabled tool is revoked: actions that depend on it go back for re-authorization and their unused admissions are invalidated. Nothing that depends on it can be admitted or executed until it is re-enabled.

Change retention

Where: Administration → Retention → Change on a policy. Form: New minimum retention (days), Reason → Propose retention change.

Blocked below the policy's regulatory floor, or when the number isn't a whole number of days. A change that keeps the current period is blocked as no change.

Withdraw a pending change

Open the action (Administration → Administrative change log, or the agent's record) and choose Withdraw request. The decision is retired, approvals and any unused admission are invalidated, the action becomes DISCARDED, and the target is free for a new change. A proposed action that was never evaluated has Discard instead. An executed change can't be withdrawn; reverse it with a new change.

Reject or send back a change

Where: Approvals tab → Reject or request changes on a pending approval. Form: Reason (required, recorded in the evidence).

• Request changes returns the change to the requester. That revision can't be evaluated again; the requester saves a new revision, which needs fresh approvals.
• Reject (final) ends it. It can't be resubmitted or revived by any client; a new change must be proposed.
• Either way the decision is retired and approvals already given stop counting. Use reject when the change shouldn't happen at all; use request changes when it's the right change with the wrong details.

Decide a research access request

Research that asks for connected-private or sensitive cross-source data waits at Authorization required until a Security Administrator decides. Where: Research → the research → Access request. Form: Reason (required) → Approve access or Deny (ends the research).

• The requester can never decide their own request. In the sample the decision is recorded under T. Nakamura (simulated).
• Approve only when the purpose needs that data. Approval opens those source types for that one research; it grants nothing else and authorizes no action.
• Private sources are never fetched from the network. Their excerpts are pasted in and labeled with the approved type, and the synthesis is marked contains private evidence.
• A request lapses after 72 hours and then can't be decided; the research must be requested again.
• If removing a role would leave no Security Administrator other than the requester, access requests can't be decided: the card says no eligible Security Administrator. The role-removal check doesn't count research access yet, so check this before removing the role.

Record an agent revalidation

When an agent's version changes, a request with a consumer-facing effect is held until the new version has been revalidated. A revalidation records that the current version was checked; it changes no authority and executes nothing. Where: Administration → choose the agent's name; the agent's record shows Revalidation needed beside Validated version, with the last validated version. Form: What was revalidated (at least 10 characters, for example the regression pack and samples you reviewed on this version) → Record revalidation.

• Only a Security Administrator who is not the requester can record it. In the sample the decision is recorded under a simulated Security Administrator.
• Revalidate only after the checks you describe have actually been run on this version. The note is the record of them.
• For an effect that is not consumer-facing, a changed version only produces a warning, so nothing is held.
• If nobody who holds the role is eligible, the revalidation is refused and the held request stays held.

5. Routine checks

• Evidence chain. Dashboard → Recompute hashes now, or Inspector → Reconstruct and verify. Any altered or missing event breaks the chain and is pinpointed.
• An agent's history. Administration → choose the agent's name. Its record lists every administrative change (each opens the action) and its record history.
• Administrative change log. Administration, bottom of the page: every change with its effect, decision and status.
• Evidence packages. Reports & Assurance → Generate action package for one change end to end.
• Research access. TrustDNA Evidence: each RESEARCH_ACCESS_APPROVED or RESEARCH_ACCESS_DENIED event names the source types, the approver and the reason. Review approvals against their stated purpose.
• Handoffs. The Handoffs menu item shows a count of open handoffs. Each is a blocked or held request that must reach a named owner, who acknowledges it within four business hours or it escalates. Look for any that are open or escalated, and for outcomes that were recorded without a reason.
• Legal Intelligence. TrustDNA Evidence: LEGAL_DRAFT_PRODUCED, LEGAL_ACTION_BLOCKED, LEGAL_ACTION_HELD and COUNSEL_REVIEW_RECORDED events. A counsel review is a licensed attorney's self-attested decision on a draft; DISCINTEL cannot verify a licence, so check that the reviewer named is who you expect. Approval authorizes no external action.
• Regulatory snapshot. On an EU decision, the regulatory context shows the snapshot's as of date. After 120 days it says it may be out of date; updating the snapshot is a governed release.
• Runtime governor. Decisions, tool calls and research retrievals each carry the DMGG verdict (DMGG shadow: ALLOW). A shadow BLOCK on something the app allowed is a would-change decision to review before enforce.

6. When something goes wrong

Questions: legal@getdiscintel.com. Security reports: privacy@getdiscintel.com.

DISCINTEL, LLC · Early access. The sample institution and its people, approvers, sanctions list and payment rail are fictional or simulated.