Waypoint™

Waypoint™ Governance, Gates and Human Control

1. Purpose

Waypoint™ is intended to perform substantial project work autonomously. Governance must therefore be part of the execution architecture rather than a collection of warnings around autonomous agents.

The objective is:

Maximize safe autonomous progress while reserving human attention for consequential decisions, exceptions, and accountability.

2. Governance model

Governance spans:

  • Design;
  • Plan;
  • Execute;
  • Deliver;
  • workers;
  • tools;
  • environments;
  • data;
  • cost;
  • approvals;
  • change;
  • evidence;
  • audit.

Policies should be evaluated by the Control Plane at the point where authority is required.

3. Principles

G1 — Explicit authority

Ability is not authority. A worker that can technically perform an action may still be prohibited from doing so.

G2 — Least privilege

Workers receive only the access required for authorized work.

G3 — Independent approval

A worker may not approve its own action when policy requires independent review.

G4 — Evidence-based gates

Approval should be based on visible design, plan, test, risk, or delivery evidence.

G5 — Interruptibility

Humans must be able to pause or stop autonomous progress.

G6 — Auditability

Material decisions and actions must be reconstructable after the fact.

G7 — Policy before prompt

Critical security/governance rules must be enforced structurally, not merely described in an agent prompt.

G8 — Minimize approval fatigue

Low-risk routine actions should proceed under policy without repeated human confirmation.

4. Gate abstraction

A Gate represents a governed condition required before lifecycle progression or a controlled action.

A gate should include:

  • gate ID/type;
  • scope;
  • trigger;
  • required conditions;
  • required evidence;
  • required approver role/identity;
  • decision;
  • conditions/exceptions;
  • expiration if applicable;
  • artifact/version approved;
  • audit record.

5. Standard lifecycle gates

5.1 Design Gate

Approves a specific Project Design Package version for planning.

5.2 Plan Gate

Approves a specific Execution Plan version or bounded increment for execution.

5.3 Execution Authorization Gate

Authorizes autonomous execution at a defined scope.

Scope may be:

  • project;
  • phase/release;
  • sprint;
  • stream;
  • work package;
  • individual work item.

5.4 Quality/review gates

May include:

  • architecture;
  • security;
  • code;
  • data;
  • QA;
  • compliance;
  • operational readiness.

5.5 Delivery Gate

Authorizes mutation of the intended delivery target.

5.6 Acceptance Gate

Accepts the delivered outcome.

6. Conditional gates

Projects may define gates triggered only under specific conditions.

Examples:

  • infrastructure change exceeds cost threshold;
  • migration affects production data;
  • security-sensitive file changed;
  • destructive database operation detected;
  • agent requests new permission;
  • delivery occurs outside normal window;
  • test coverage falls below policy.

This reduces unnecessary approvals while preserving control.

7. Approval scope and versioning

An approval must identify exactly what was approved.

Examples:

  • Design Package v3;
  • Execution Plan v5;
  • release 1.2;
  • deployment artifact SHA;
  • infrastructure plan hash.

Material change may invalidate prior approval.

Waypoint™ should calculate approval impact rather than silently carrying approvals forward.

8. Roles

Waypoint™ should support configurable governance roles such as:

  • project owner;
  • design approver;
  • technical approver;
  • security approver;
  • plan approver;
  • execution operator;
  • delivery approver;
  • acceptance owner;
  • administrator.

One person may hold multiple roles where policy permits.

9. Human decision queue

The Overseer experience should provide a consolidated queue of decisions requiring attention.

Each item should show:

  • what is waiting;
  • why human action is required;
  • impact of delay;
  • recommended decision;
  • alternatives;
  • relevant evidence;
  • affected project/work;
  • risk;
  • expiration/window.

The user should not have to search Jira tickets to discover governance decisions.

10. Approval actions

A reviewer should be able to:

  • approve;
  • approve with conditions;
  • reject;
  • request changes;
  • defer;
  • delegate if policy permits;
  • escalate.

Conditions should be structured and traceable.

11. Policy engine

The Control Plane should eventually include a policy evaluation capability.

Policy inputs may include:

  • project;
  • lifecycle stage;
  • worker;
  • action;
  • environment;
  • resource;
  • data classification;
  • cost;
  • risk;
  • test/evidence state;
  • time/window;
  • approval state.

Policy outputs may include:

  • allow;
  • deny;
  • require approval;
  • require additional evidence;
  • restrict scope;
  • require specific worker/reviewer;
  • require rollback protection.

12. Risk classification

Work/actions may be classified by risk.

Potential dimensions:

  • production impact;
  • destructive potential;
  • security sensitivity;
  • data sensitivity;
  • financial cost;
  • reversibility;
  • customer impact;
  • compliance impact;
  • blast radius.

Risk should influence autonomy and gate requirements.

13. Secrets and credentials

Waypoint™ should store references to secrets in appropriate secure systems rather than placing credentials in project documents, Jira, prompts, or logs.

Governance should control:

  • which worker may request a credential;
  • which environment/resource it can access;
  • allowed operations;
  • duration;
  • rotation/revocation;
  • audit.

Short-lived credentials are preferred where supported.

14. Data governance

Projects may contain sensitive data or artifacts.

Waypoint™ should support:

  • project/data classification;
  • worker/environment restrictions;
  • redaction;
  • minimum-context execution packages;
  • logging restrictions;
  • retention policy;
  • external-model/provider restrictions.

15. Cost and budget governance

Autonomous execution can create compute, model, cloud, and service cost.

Waypoint™ should support:

  • project budgets;
  • warning thresholds;
  • hard limits where practical;
  • estimated cost before high-cost actions;
  • actual cost collection;
  • approval above threshold;
  • cost reporting.

16. Change governance

Changes should be classified as:

  • clarification;
  • design change;
  • plan change;
  • execution variance;
  • emergency remediation;
  • delivery exception.

Policy determines:

  • who may initiate;
  • what artifact must be versioned;
  • which approvals reopen;
  • what execution pauses;
  • what reporting/audit is required.

17. Exception management

An exception is an authorized deviation from normal requirement/policy.

Exception records should include:

  • requirement/policy;
  • reason;
  • scope;
  • risk;
  • approver;
  • expiration;
  • compensating control;
  • affected artifact/work;
  • closure status.

Exceptions should never be hidden inside free-text comments only.

18. Emergency controls

Waypoint™ should support:

  • prevent new dispatch;
  • pause project;
  • pause stream;
  • revoke worker;
  • revoke environment access;
  • cancel queued work;
  • request active cancellation;
  • block delivery;
  • emergency stop.

The UI must clearly distinguish:

  • stopped safely;
  • stop requested;
  • external operation still active;
  • state unknown/reconciliation required.

19. Audit

Audit events should capture material actions including:

  • design/plan approvals;
  • policy decisions;
  • permission changes;
  • worker assignment;
  • external mutation;
  • test/evidence result;
  • exception;
  • pause/stop;
  • delivery;
  • rollback;
  • acceptance.

Audit records should identify actor, time, project, scope, action, outcome, and correlation/run identifiers.

20. Evidence

Evidence may include:

  • test reports;
  • build logs;
  • PR/review identifiers;
  • deployment identifiers;
  • screenshots/artifacts where appropriate;
  • infrastructure plans;
  • data reconciliation;
  • approval records;
  • checksums/hashes;
  • external system state.

Evidence should be linked, immutable where practical, and retained according to policy.

21. Separation of duties

Waypoint™ should support separation-of-duty rules.

Examples:

  • implementation agent cannot approve its production delivery;
  • infrastructure author cannot approve a high-risk production apply;
  • security exception requires security authority;
  • acceptance must come from designated owner.

Rules should be configurable by project/organization.

22. Notifications

Governance events should generate actionable notifications for:

  • gate waiting;
  • blocker;
  • execution failure;
  • stalled worker;
  • budget threshold;
  • high-risk exception;
  • delivery failure;
  • rollback;
  • acceptance required.

Notification channels should be adapters rather than hard-coded.

23. Governance reporting

The reporting API should expose:

  • gates pending/completed;
  • approval turnaround;
  • policy denials;
  • exceptions;
  • high-risk actions;
  • permission changes;
  • stop/pause events;
  • audit history;
  • evidence completeness;
  • budget thresholds;
  • acceptance state.

24. Initial completion criteria

Governance is sufficient for initial Waypoint™ when it supports:

  1. Design, Plan, Execution, Delivery, and Acceptance gates;
  2. scoped execution authorization;
  3. roles/approvers;
  4. approval version binding;
  5. worker/action/environment authorization;
  6. pause/stop controls;
  7. exceptions;
  8. audit events;
  9. evidence;
  10. basic cost controls;
  11. a human decision queue;
  12. reporting API exposure.