[Design] Evaluate embedded IntentFlow v1 action-assurance enforcement

[dgenio]

Context

IntentFlow is narrowing to a formal action-assurance language/compiler/verifier rather than another execution runtime:

• [v1 Epic] Action-assurance language, formal semantics, and independent verification intentflow#149 — v1 epic
• [v1] Specify canonical assurance transaction artifacts and versioning intentflow#151 — canonical transaction artifacts
• [v1] Build the normative conformance and adversarial corpus intentflow#154 — conformance corpus

agent-kernel already owns embedded capability authorization, execution, output firewalling, and audit in the Weaver Stack. It is therefore the natural candidate implementation of IntentFlow's embedded enforcement profile.

Goal

Evaluate how agent-kernel could consume a canonical AssurancePlan, bind a capability invocation to an exact ActionRequest, and emit a portable DecisionAttestation without replacing its native capability or policy model.

Design questions

• How does a CapabilityRequest map to ActionRequest/v1alpha1?
• Which current token fields are insufficient for exact argument, plan, run, tool-descriptor, and pre-state binding?
• Can native PolicyDecision and CapabilityToken artifacts be referenced by digest as obligation evidence?
• How should single-use approval consumption interact with revocation and token TTL?
• Which execution and postcondition facts can be represented in ExecutionReceipt?
• How does the portable attestation relate to ActionTrace and Frame without duplicating operational logs?
• Which guarantees are possible in an embedded profile where the host may retain direct tool access?

Deliverable

A design note and thin adapter spike, not a production integration, containing:

• artifact mapping table;
• trust and bypass analysis;
• required kernel API changes;
• conformance cases the adapter must pass;
• recommendation to proceed, defer, or reject.

Acceptance criteria

• The design preserves agent-kernel ownership of embedded execution and the Frame seam
• It does not introduce a second policy language into the kernel
• It explicitly limits the guarantee to submitted calls unless the deployment provides stronger mediation
• Existing token/audit claims are compared against exact v1 transaction requirements
• The spike can produce a synthetic attestation accepted by the IntentFlow verifiers
• No implementation proceeds until the v1 artifact drafts stabilize

Non-goals

• Replacing AgentFence as the credential-isolated reference gateway
• Moving Lean or the .iflow compiler into agent-kernel
• Claiming complete mediation for an ordinary in-process library