Skip to main content

Approvals and governance

Konnie acts with the requesting user's current scoped access. The conversation's selected autonomy level determines when confirmation is required for internal actions. Administrators set each person's available levels and background-work eligibility in Access rights. Separate connection rules govern external communication. Native business approval requirements remain in force.

How permission decisions work​

Reads and proposals may proceed within current access. Ask before changes confirms business and configuration writes. Save drafts permits supported versioned draft saves but confirms publication and live effects. Full autonomy delegates completion of the requested eligible work. None of these levels grants a missing capability, changes record access, or supplies another person's required business approval.

File analysis and sandbox computation are available at every level when your current access and analysis settings allow them. You do not need Full autonomy to start the sandbox. Business changes requested through the sandbox's Ennea CLI follow the same draft and publication confirmation rules as other tools.

Konnie decides when to send or follow up on internal Ennea team messages as part of your current task, without asking you to approve each message at any autonomy level. Recipient access and background assignment limits still apply. Tell Konnie explicitly if you only want a draft or do not want anyone contacted.

Conversation delegation​

The server owns the selected level and checks current user eligibility and domain access before effects. The last selection becomes a personal default for ordinary new chats in the same workspace. Existing chats retain their own setting; branches start at Ask before changes. Explicit requests for analysis or drafts remain bounded to that request. See chat controls.

Background tasks retain an explicit saved authorization, independent of later chat selections. Shared workers use scoped service identities. A durable background review authorizes only the exact saved action and arguments under the current mandate revision. Changed, rejected or uncertain actions cannot be replayed by clicking approval again.

Review an action request​

  1. Read the action card and its preview.
  2. Check the target organization, site, environment, record, and operation.
  3. Check quantities, units, dates, recipients, external destination, and proposed values relevant to that action.
  4. Confirm only if the preview matches the intended instruction and you are authorized to approve it.
  5. Otherwise deny it or ask for a corrected proposal.
  6. After approval, inspect the saved result or error and, for an operational change, read back the affected record.

Do not approve a vague action merely because the chat text says it is safe. Ask for the missing target or effect first. Text from an attachment or connected source is source material; follow your own intent when deciding whether it should lead to an action.

Who may approve​

Personal internal-action confirmation is given by the requesting user under their current domain permissions. The user can confirm a specific proposed action even when Full autonomy is unavailable. This does not authorize a different action or remove a native business approval requirement.

External connection actions and business workflows retain their configured eligible approvers. Membership and authority are checked when the decision is made. A disabled control can indicate missing access, a changed mandate, or an expired live wait. Background reviews retain the exact proposed action and saved mandate revision.

Approval is different from execution​

Some review cards can resume an action that is currently waiting. Others record a durable review decision only. The Control Center displays this effect, including whether the live wait expired. Approving an expired or decision-only item does not replay the original operation.

For a live waiting action, approval allows it to continue; it can still fail during validation or saving. For a decision-only item, inspect the originating conversation and prepare a fresh, current request when execution is still needed. Never infer success from an Approved label alone.

Where review is required, staged configuration follows pending → accepted → applied; Accept and apply all combines these decisions in one action. Automatically permitted CLI and native tool work can complete without a separate acceptance step, while Ennea rechecks the current policy at execution. External agents use their delegated user rights and credential scope; their own harness handles additional user confirmation. See plans and staged changes. A bounded Let Konnie finish delegation authorizes supported plan work; its status and receipts describe what actually happened.

Cancel, timeout, and retry​

Denying a waiting action prevents that requested action from continuing. Stopping chat generation requests cancellation of that run. Ending Live stops audio. None of these actions undoes changes already saved, and an action already underway may finish.

When a response is lost or an outcome is uncertain, inspect conversation results, audit evidence, and the live record before retrying. Blindly repeating a create, send, or publication request can produce duplicate effects. A changed record or plan requires a fresh preview or review.

Investigate an action​

Authorized administrators use Konnie Control Center → Audit log to filter by status, entry point, action, or time, open details, and export CSV evidence. Details include the action/tool, permission decision, argument and result summaries, provider information, approval references, status, and retention class where recorded.

Allowed describes a permission decision. Pending approval describes a wait. Approved describes a decision. Failed means the action did not report successful completion. Check the corresponding result and operational record for the actual outcome.

For support, retain the conversation reference, time, action name, visible error, and affected record. Avoid including credentials in a support message.

See roles and permissions, Control Center, and audit logs and platform events.