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

Trust boundary map

Architecture-defined
GOVERNING CLAIM

Authority, Factory, runtime, external consequence, and evidence domains require separate controls and identities.

INTENT → FACTORY → RUNTIME → CONSEQUENCE → VERIFICATION
  1. 01
    Intent domainPrincipals and policy holders establish authority.
  2. 02
    Factory domainPackages, evaluators, and projections are prepared.
  3. 03
    Runtime domainAgents reason without owning consequence authority.
  4. 04
    Evidence domainReceipts cross to independent consumers.
FOLLOW PRIMARY FLOWLEFT / TOP→RIGHT / BOTTOM
READ THE FLOW

Look for every point where intent, policy, identity, deployment, action, receipts, or verification crosses into another trust domain.

  1. 01

    Treat every domain crossing as a control decision.

  2. 02

    Identity is bound before runtime work begins.

  3. 03

    External actions cross a distinct consequence boundary.

  4. 04

    Verification remains outside the producer's trust domain.

WTK IMPLEMENTATION OBSERVATION

WTK represents contracts, protected evaluation, projection, identity context, receipts, and consumer-facing evidence as separate governed artifacts.

REMAINS UNPROVEN

Independent attestation, multi-operator boundaries, collusive-agent behavior, and external verifier interoperability remain open.

FALSIFICATION PRESSURE

Delegation integrity · Evidence authenticity

CANONICAL SOURCEdiagrams/trust-boundaries.mmd

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