Product-Facing Intent Outcome API

[flyingrobots]

Migrated from Method backlog

This issue was created from a legacy filesystem backlog card. GitHub Issues are now the live work tracker; repository docs remain Method evidence.

Source backlog: docs/method/backlog/v0.1.0/PLATFORM_product-facing-intent-outcome-api.md
Original lane: v0.1.0
Original legend: PLATFORM

Original backlog card

Product-Facing Intent Outcome API

Status: implemented local core surface; adapter polish remains.

Depends on:

• Durable witnessed submission persistence
• Contract obstruction taxonomy
• Contract-aware receipts and readings

Why now

Echo has internal correlation between witnessed submissions, admission tickets,
ticketed runtime ingress, and tick receipts. A developer building on Echo needs
a small app-safe API that says what happened to a submitted intent without
exposing scheduler control.

Shape

The product-facing surface should support the equivalent of:

let submission = echo.submit_intent(intent_bytes)?;

match echo.observe_intent_outcome(submission.id)? {
    IntentOutcome::Pending { .. } => {}
    IntentOutcome::Applied { receipt, .. } => {}
    IntentOutcome::Rejected { reason, blocked_by, .. } => {}
    IntentOutcome::Obstructed { obstruction, .. } => {}
    IntentOutcome::Unknown { .. } => {}
}

The exact names may differ, but the authority boundary may not.

Current local core surface:

• WorldlineRuntime::submit_app_intent(...);
• IntentSubmissionHandle;
• WorldlineRuntime::observe_app_intent_outcome(...);
• IntentOutcome;
• IntentOutcomeReceipt.

The remaining work is adapter/API polish above this core surface.

Acceptance criteria

• Submitting an intent returns stable submission identity and generation.
• Submission does not tick, dispatch handlers, or mutate application state.
• Outcome observation can report unknown, pending, applied, rejected, and
  obstructed states.
• Applied/rejected outcomes bind to the relevant tick receipt evidence.
• Contract-backed applied/rejected outcomes expose retained receipt evidence
  posture where Echo can lawfully name the coordinate.
• Obstructed outcomes use the contract obstruction taxonomy.
• Missing contract receipt material is reported as missing retention for the
  retained receipt coordinate, not as an empty success.
• The API exposes no trusted runtime control and no tick/step command.
• Duplicate submission behavior is documented and tested.

Non-goals

• Do not implement streaming subscriptions.
• Do not add hidden retry.
• Do not expose trusted scheduler control to application code.
• Do not make submit_intent mean "run this now."

[coderabbitai]

🔗 Related PRs

#358 - feat(core): add admission evidence boundaries [merged]
#360 - feat(core): stage ticketed ingress and outcome observation [merged]
#368 - feat(core): connect installed contract intent pipeline [merged]
#369 - docs: add Echo v0.1.0 release plan [merged]
#371 - feat(core): advance v0.1 contract evidence and retention [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!