Skip to content

Observability MVP: recorder, decision receipts, and account/user_def routing provenance #5

@phenomenoner

Description

@phenomenoner

Why

A card runtime without receipts is just a faster way to get confused. The first implementation path needs observable decisions and explicit routing provenance.

Scope

  • define recorder / audit artifacts for:
    • market events
    • feature snapshots or hashes
    • emitted intents
    • risk decisions
    • execution requests / broker receipts
  • normalize order lifecycle events with account and routing metadata
  • require routing/filtering by active account number and user_def

Acceptance criteria

  • a reviewer can trace which card/version emitted an intent and what happened next
  • mixed order changes / fills / active reports do not bleed across cards or accounts
  • recorder behavior is suitable for replay receipt generation
  • observability work stays compatible with low-latency hot-path constraints

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:runtimeRuntime, replay, adapters, and observabilityv0.1Seed runtime v0.1 backlog

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions