Approval governance
Design approval boundaries around proposals, reviewers, evidence, escalation, and separation-of-duties limitations.
Approval governance
Approvals add a human decision between a proposal and a supported action. They are most useful when the reviewer can understand the resource, expected side effect, risk, and evidence before accepting or rejecting the request.
Ethen contains approval concepts and visible approval surfaces, but durable persistence, reviewer roles, escalation routing, and enforced separation of duties are not established across the platform. This guide defines a conservative governance model without presenting preview controls as production authorization.
Approval model
An approval begins with a proposal. The proposal should identify the requested action, target resource, requester, product, and expected outcome. The approval decision should be separate from the proposal so that rejection does not look like a failed execution and approval does not look like proof of completion.
Known states can include approval required, approved, rejected, or blocked, depending on the product. The exact state machine remains product specific. A scaffolded Approvals card may demonstrate intended interaction without persisting a signed decision.
Approvals should occur before the side effect they govern. Post hoc review is audit or triage, not approval.
Proposal-to-decision sequence
A reviewable approval flow has at least four separate records or states:
- the requester creates a proposal;
- policy or product logic determines that review is required;
- an authorized reviewer records a decision;
- the runtime attempts the supported action and records its result.
Keeping those stages separate prevents a common reporting error. “Approved” does not mean “executed,” and a failed execution does not erase the approval decision that preceded it. Similarly, a simulation or preview can support the proposal without becoming the action itself.
The proposal should be stable enough for the reviewer to know what will happen after approval. If the target, provider, resource, or diff can change silently, the approval is too broad. Material changes should create a new proposal or return the item to review.
Current products vary in how much of this sequence they persist. A visible approval state can be informative while still requiring the approval-persistence-unverified flag.
Approval expiry and conditions
A decision can become stale when the proposal changes, the provider route changes, the target resource changes, or the approved time window passes. Universal approval expiry is not established; materially changed proposals should return for a new decision.
Conditional approvals should state the condition in verifiable terms, such as a named project, provider, maximum estimated cost, or specific diff. Avoid vague approval language that can authorize unrelated future work.
The requester should be able to see whether the item is pending, rejected, approved, blocked, or completed without those states being collapsed. That clarity prevents repeated submissions and makes later review easier.
Roles
A requester asks for the action, a reviewer evaluates it, and an operator or runtime may carry it out after approval. One person can hold more than one role in a small deployment, but the documentation should not imply that a complete enterprise role model enforces those distinctions.
Define who may approve each action class. Provider credential changes, source-code proposals, high-cost requests, and destructive operations may need different reviewers. The role should be derived from a trusted identity and resource relationship rather than a client-selected label.
SSO, directory groups, automated provisioning, and organization-wide approval roles are not verified.
Authority by action class
Approval authority should follow the action’s impact. A low-cost model request may require no human decision, while changing a provider credential or allowing a source-code change can require a reviewer who owns that resource.
Useful action classes include:
| Action class | Reviewer concern |
|---|---|
| Provider access | Account ownership, data destination, and credential scope |
| Policy exception | Reason, affected resource, duration, and compensating control |
| Cost increase | Estimate source, budget effect, and whether the value is invoice grade |
| Patch proposal | Authorized repository, diff content, tests, and non-application boundary |
| Data export or deletion | Ownership, legal obligation, related copies, and provider impact |
| Production configuration | Environment, rollback, and affected routes |
The current platform does not prove that these roles are enforced centrally. A customer may adopt this model operationally, but the documentation must distinguish that practice from implemented role enforcement.
Conflicts of interest
A reviewer should disclose when they own the requested change, provider account, or affected resource. For high-impact actions, assign another reviewer where practical. The platform does not enforce this relationship automatically.
If no independent reviewer is available, use compensating controls such as a second-person post-change review, narrow provider scope, or a temporary policy restriction. Record that the technical separation was unavailable.
Evidence
A reviewer needs enough evidence to make the decision without receiving unnecessary secrets. Useful context can include a human-readable action summary, affected resource, provider or tool, risk class, policy reason, proposed changes, and relevant simulation or dry-run output.
Evidence should indicate whether it is live, sample, fixture, or preview. A generated diff can support review, but it does not prove that the diff can be applied. A provider estimate can inform cost review, but it is not a bill.
Store the decision with the proposal identifier and actor identity where the product supports persistence. Current persistence gaps must remain visible.
Reviewer packet
A concise reviewer packet should answer:
- what action is proposed;
- who requested it;
- which project, repository, provider, or resource is affected;
- what policy caused review;
- which data or external side effect is involved;
- what simulation, diff, estimate, or validation exists;
- what remains unknown;
- how the result can be verified after approval.
Omit raw secrets. If a credential change is under review, identify the provider and credential label rather than the value. If a repository proposal is involved, include the relevant diff and authorized scope rather than unrelated source.
Evidence freshness matters. A provider readiness check or cost estimate can become stale before the reviewer acts. The packet should show when dynamic information was collected.
Evidence gaps
A reviewer should be able to return the proposal when a required fact is missing. Common gaps include unknown project ownership, unverified provider destination, stale cost estimate, absent diff, missing data-class approval, or unclear rollback.
The correct response to missing evidence is not a broad approval with assumptions. Keep the item pending, narrow it, or reject it until the decision can be made from verified information.
Escalation
Escalation is appropriate when the assigned reviewer lacks authority, the evidence is incomplete, or the action crosses a policy or legal boundary. No central escalation workflow or response-time commitment is established.
An escalation record should state what decision is needed, why the current reviewer cannot make it, which resource is affected, and what deadline exists outside Ethen. Avoid forwarding raw credentials or sensitive content when a summary and identifier are sufficient.
Use the approved Help or Contact route only for product assistance. Those routes do not create an enterprise approval or incident SLA.
When not to approve
A reviewer should escalate or reject when the proposal lacks an owner, the target is outside the requester’s authority, required evidence is unavailable, the provider destination is unclear, the action conflicts with policy, or the reviewer is also the only person able to execute a high-impact change.
Escalation should identify the missing decision rather than forwarding the entire item without context. For example: “Security review is required for a new provider destination,” or “Project ownership is unresolved for this credential change.”
If no approved destination or role exists, the correct state is pending or blocked. Do not create an informal approval simply to move the workflow forward.
Separation of duties
Separation of duties reduces the chance that one identity can propose, approve, and execute a high-impact change without independent review. The principle is relevant to credential changes, provider access, policy exceptions, patch proposals, billing configuration, and incident containment.
Enforced separation is not proven across every product. Where the product cannot enforce it, customers can assign different people and retain an external decision record, but that process should not be described as an Ethen feature.
Do not use a sample or non-persisted approval surface as the sole control for a production action.
Compensating controls
Where technical separation is unavailable, customers can use procedural controls: require a second person to review the diff or configuration, record the decision outside Ethen, limit provider-account permissions, or schedule a post-change verification by someone other than the operator.
These measures reduce risk but are not equivalent to platform-enforced separation. The requester may still be able to call the underlying API directly if authorization is incomplete. Sensitive deployments should therefore verify the server boundary, not only the review process.
Separation also matters during incident response. The person investigating a suspected credential misuse should not be the only person authorized to alter or delete the evidence.
Audit
An approval audit record should distinguish the proposal, decision, actor, time, reason, and execution result. Approval is not the same as execution: an approved action may still fail, be cancelled, or never start.
The general audit route is Sample and Private Alpha. It cannot currently serve as evidence that every approval decision is durably ingested or exportable. Product-specific records may provide more useful correlation, but their persistence must be checked.
For review, trace the chain from policy outcome to approval decision to the actual side effect. Gaps should be documented rather than filled with inferred events.
Decision audit fields
An approval event is most useful when it includes the proposal ID, decision, reviewer identity, timestamp, reason, evidence references, and any expiry or condition. The execution result should carry its own status and correlation identifier.
If the decision is changed, retain the history where the product supports it rather than overwriting the earlier state. No platform-wide immutable history is verified, so customers should not rely on that behavior without testing the specific product.
Sample audit fixtures can demonstrate the intended fields but cannot prove that a real reviewer made the decision. Label the data source whenever an approval record is used in a report.
When a reviewer rejects a proposal, preserve the reason where the product supports it. The reason can help a requester correct scope, provider, evidence, or risk without repeatedly submitting the same unsafe action.
Do not include sensitive content beyond what the decision requires. A concise reason and stable proposal reference are preferable to copying an entire prompt, repository file, or credential-related configuration into the audit record.