WTKRESEARCH + ENGINEERING

PUBLISHED REFERENCE MATERIAL

Follow the claim to its evidence.

Start with a research question, inspect the proposed architecture, then separate implementation observations from validation evidence and open gaps. Publication here does not make a pattern true.

WTK / TARGET-STATE FLOW

Consequential action authorization

Partially implemented
GOVERNING CLAIM

Agents propose actions; an accountable substrate decides whether those actions may produce consequences.

PROPOSE → CHECK → ESCALATE OR DENY → EXECUTE → RECEIPT
  1. 01
    ProposeThe agent requests an action in structured form.
  2. 02
    AuthorizePolicy, scope, identity, and budget are checked.
  3. 03
    ResolveA human gate approves, or the system denies safely.
  4. 04
    ReceiptExecution and consequence evidence are bound.
FOLLOW PRIMARY FLOWLEFT / TOP→RIGHT / BOTTOM
READ THE FLOW

Separate the untrusted proposal path from authorization, human escalation, external execution, receipt capture, and safe denial.

  1. 01

    A proposal is not permission.

  2. 02

    High-impact ambiguity routes to a human gate.

  3. 03

    Denied actions terminate in an explicit safe state.

  4. 04

    Execution is incomplete until its receipt is captured.

WTK IMPLEMENTATION OBSERVATION

WTK defines narrowed role contracts, operator gates, structured denials, bounded handoffs, and attributable activity evidence.

REMAINS UNPROVEN

Target-side identity, nonce and replay enforcement, expiry, budget controls, and consequence semantics are not uniformly enforced across adapters.

FALSIFICATION PRESSURE

Evidence authenticity · Organizational acceptance

CANONICAL SOURCEdiagrams/action-authorization.mmd

Topology and labels are source-controlled. Presentation is supplied by the site renderer.