Outcomes

A receipt records what the gateway saw. An outcome records whether the call did what the user wanted. Outcomes are the bridge from “we ran a call” to “the call solved the problem” — and they feed the compounding loop:

receipts → outcomes → memory candidates → reviewer-promoted patterns → better future calls

The data model

Every outcome is anchored on a receipt_id and is append-only — receipts themselves are never mutated. Schema:

Field	Type	Notes
`id`	UUID	Outcome row id.
`receipt_id`	UUID	The receipt this outcome describes. Required.
`outcome`	enum	One of 11 values (see below).
`source`	enum	`self_report`, `human_reviewer`, `webhook`, `automated_test`, `agent_runner`.
`score`	float \| null	Optional 0..1 confidence.
`labels`	string[]	Optional tags (“auth-fix”, “regression”, etc.).
`notes_hash`	sha-256 \| null	If notes were submitted, the server hashed them. Raw text never persists.
`submitted_by_user_id`	UUID \| null	When `source = human_reviewer`.
`created_at`	timestamp	Append-only.

`outcome` enum (11 values)

succeeded — the call did what was asked.
partially_solved — partial progress.
failed — the call did not succeed.
no_progress — the call ran but accomplished nothing.
regressed — the call made the situation worse.
user_satisfied — explicit user approval.
user_unsatisfied — explicit user rejection.
tool_chain_succeeded — the agentic tool chain reached a successful end state.
tool_chain_failed — the agentic tool chain failed.
review_pending — outcome not yet known.
out_of_scope — the call was outside the agent’s mandate.

`source` enum (5 values)

self_report — submitted by the agent or app on its own behalf. Trust tier “user-supplied.”
human_reviewer — submitted by a human reviewer in lair.
webhook — submitted by a trusted-integration webhook (V-27c — pending).
automated_test — submitted by an automated test harness (V-27c — pending).
agent_runner — submitted by a runner that drove the agent.

Submitting an outcome

curl https://api.prxy.monster/v1/outcomes \
  -H "Authorization: Bearer $PRXY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "receipt_id": "8c5a4e2a-...-...",
    "outcome": "succeeded",
    "source": "agent_runner",
    "labels": ["auth-fix"],
    "notes": "User reported the auth bug is gone after this turn."
  }'

The notes field is hashed sha-256 server-side at write time. The raw string never persists. Reviewers in lair never see the raw note — only the hash and the structured outcome / labels.

Listing outcomes

curl https://api.prxy.monster/v1/receipts/<receipt_id>/outcomes \
  -H "Authorization: Bearer $PRXY_KEY"

Returns the append-only list of outcome rows for that receipt.

How outcomes feed memory

Positive outcomes (succeeded, partially_solved, user_satisfied, tool_chain_succeeded) feed the memory_candidates queue. A reviewer in lair (/dashboard/admin/memory-candidates) promotes useful candidates into the patterns table — and patterns ride into future calls via the patterns module.

We never auto-promote. Every promotion is a human decision. See Memory candidates.

Trust tiers (planned)

V-27d adds a trust_tier column on inference_outcomes. Self-reported outcomes are weighted lower than reviewer-confirmed or trusted-integration outcomes. Until V-27d ships, treat all outcomes as equal weight.