Decision Memory
Use the existing file-native decision packages, research artifacts, source
snapshots, replay manifests, forecast ledger, postmortems, and improve records.
Treat generated summaries, links, and Wiki-style pages as read views, never as
the canonical record.
Choose The Mode
- Retrieve: find relevant prior decisions, forecasts, evidence, outcomes,
and lessons. Preserve contrary and retired records; do not return only
successful cases.
- Replay: freeze an as-of time and use only source snapshots knowable by
that cutoff. Record the ResearchSpec and replay manifest before revealing the
outcome.
- Review: compare the frozen decision process with the resolved outcome.
Assess process quality before revealing P&L or outcome quality, then keep the
two judgments separate.
- Validate: compare a lesson candidate across independent episodes,
historical holdout periods, regimes, and live forward evidence.
Procedure
- Identify the subject, decision or forecast id when known, time cutoff,
evidence origin, and selected strategy snapshot. Use
no_strategy when no
strategy applied. Retrieve through the structured read-only MCP tools
available to the current role: list_workflow_artifacts,
list_research_artifacts, search_research_artifacts,
get_research_artifact, list_research_specs, get_research_spec,
list_forecasts, get_forecast, and
get_forecast_calibration_report.
- For a current decision, record the independent initial view before retrieving
similar cases. After retrieval, show what changed and why. When Memory changes
a synthesis, store only the compact
memory block: cutoff, initial view,
canonical Judgment/Postmortem/Lesson refs, and a delta direction of
unchanged, strengthened, weakened, or reversed with its reason. Omit
the block entirely when Memory was not used; the receipt seals exact hashes.
- For historical replay, reject sources whose
known_at exceeds the cutoff.
Preserve data vintage, universe membership, delistings, corporate actions,
costs, model/prompt/tool hashes, and every attempted hypothesis or parameter
trial when applicable. Freeze the plan and manifest through
create_research_spec and create_replay_manifest when the current role is
authorized; otherwise dispatch the smallest registered role that owns the
required MCP tool. Never substitute a shell command or caller-supplied
principal.
- Freeze forecasts and invalidation conditions before outcomes are visible.
Use the role-bound
issue_forecast, revise_forecast, resolve_forecast,
and score_forecast MCP tools for the append-only lifecycle. Dispatch the
registered independent reviewer for resolution when required by the tool
contract.
- Once an accepted synthesis has future evaluation value, Head Manager records
its immutable JudgmentSnapshot with
record_judgment_snapshot. It freezes
the canonical synthesis receipt, run context, cutoff, and forecast refs or
forecast block reason. It remains evidence_only.
- Before any outcome is recorded or revealed, reconstruct intent, evidence,
alternatives, assumptions, guardrails, and the decision-time process from
durable artifacts. Prepare a process-review payload without outcome
knowledge, then use the explicit user-terminal handoff below to lock it. Do
not invent missing events.
- Only after the process review is locked, record and independently resolve the
outcome. Prepare the second-pass postmortem payload, binding
process_review_id, the sealed DecisionSnapshot, and undisputed forecast
outcome events, then hand it to the user for the terminal action below.
Store any generalization as a lesson candidate, not as a durable rule.
Separate knowledge-base integrity errors, decision process errors, and
forecast resolution or calibration errors.
- Label lesson state as
candidate, corroborated, validated, or retired.
Record evidence origin separately as historical_replay,
historical_holdout, or live_forward.
- Promote a lesson only after independent contrary-case review and out-of-sample
evidence appropriate to its scope and regime. Dispatch the registered
independent review role; its authenticated review principal must call the
promote_lesson MCP tool. There is no direct CLI promotion path, and a
caller-supplied role is not reviewer authentication. Historical replay
evidence alone cannot become holdout or live-forward validation.
User Adoption And Terminal Handoff
Never infer that the user adopted a Judgment. When the user explicitly chooses
to adopt one, prepare a payload with judgment_id, the user's decision, and an
optional superseded adoption reference. Codex must not run the adoption command
or write the event directly. Tell the user to run it interactively:
{{TRADINGCODEX_WORKSPACE_LAUNCHER}} decision adopt <payload.json>
{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem process-review <payload.json>
{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem create <payload.json>
When an id is unknown and the structured MCP views do not expose the needed
record, hand off one read-only terminal command and ask the user to return its
output:
{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem list
{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem show <report-id>
Never claim that a handed-off command ran until the user returns its output.
Boundaries
- Do not treat LLM confidence, graph connectivity, retrieval frequency, or a
profitable outcome as proof that a claim is true.
- Do not erase superseded claims or failed cases. Link replacements while
preserving the earlier record and its decision-time context.
- Do not merge historical replay, historical holdout, and live forward metrics
into one score.
- Do not silently change a strategy, skill, prompt, role, policy, approval,
broker, or execution setting. Produce a reviewable change proposal instead.
- Do not replace a structured TradingCodex MCP operation with a launcher, shell,
or direct file edit. User Adoption and postmortem handoffs are the explicit
terminal-only exceptions.
- Do not draft, approve, or execute an order from memory evidence alone.
Return the relevant artifact paths, the applicable strategy snapshot, the
strongest supporting and contrary episodes, lesson status, evidence tier, and
the next validation needed.
1---2name: tcx-memory3description: Review past investment decisions, run point-in-time historical replays, compare resolved forecasts and forward outcomes, and validate lesson candidates. Use when the user asks what happened before, why a thesis changed, whether a strategy lesson held out of sample, or what prior evidence is relevant to a current decision.4---56# Decision Memory78Use the existing file-native decision packages, research artifacts, source9snapshots, replay manifests, forecast ledger, postmortems, and improve records.10Treat generated summaries, links, and Wiki-style pages as read views, never as11the canonical record.1213## Choose The Mode1415- **Retrieve**: find relevant prior decisions, forecasts, evidence, outcomes,16 and lessons. Preserve contrary and retired records; do not return only17 successful cases.18- **Replay**: freeze an as-of time and use only source snapshots knowable by19 that cutoff. Record the ResearchSpec and replay manifest before revealing the20 outcome.21- **Review**: compare the frozen decision process with the resolved outcome.22 Assess process quality before revealing P&L or outcome quality, then keep the23 two judgments separate.24- **Validate**: compare a lesson candidate across independent episodes,25 historical holdout periods, regimes, and live forward evidence.2627## Procedure28291. Identify the subject, decision or forecast id when known, time cutoff,30 evidence origin, and selected strategy snapshot. Use `no_strategy` when no31 strategy applied. Retrieve through the structured read-only MCP tools32 available to the current role: `list_workflow_artifacts`,33 `list_research_artifacts`, `search_research_artifacts`,34 `get_research_artifact`, `list_research_specs`, `get_research_spec`,35 `list_forecasts`, `get_forecast`, and36 `get_forecast_calibration_report`.372. For a current decision, record the independent initial view before retrieving38 similar cases. After retrieval, show what changed and why. When Memory changes39 a synthesis, store only the compact `memory` block: cutoff, initial view,40 canonical Judgment/Postmortem/Lesson refs, and a delta direction of41 `unchanged`, `strengthened`, `weakened`, or `reversed` with its reason. Omit42 the block entirely when Memory was not used; the receipt seals exact hashes.433. For historical replay, reject sources whose `known_at` exceeds the cutoff.44 Preserve data vintage, universe membership, delistings, corporate actions,45 costs, model/prompt/tool hashes, and every attempted hypothesis or parameter46 trial when applicable. Freeze the plan and manifest through47 `create_research_spec` and `create_replay_manifest` when the current role is48 authorized; otherwise dispatch the smallest registered role that owns the49 required MCP tool. Never substitute a shell command or caller-supplied50 principal.514. Freeze forecasts and invalidation conditions before outcomes are visible.52 Use the role-bound `issue_forecast`, `revise_forecast`, `resolve_forecast`,53 and `score_forecast` MCP tools for the append-only lifecycle. Dispatch the54 registered independent reviewer for resolution when required by the tool55 contract.565. Once an accepted synthesis has future evaluation value, Head Manager records57 its immutable JudgmentSnapshot with `record_judgment_snapshot`. It freezes58 the canonical synthesis receipt, run context, cutoff, and forecast refs or59 forecast block reason. It remains `evidence_only`.606. Before any outcome is recorded or revealed, reconstruct intent, evidence,61 alternatives, assumptions, guardrails, and the decision-time process from62 durable artifacts. Prepare a process-review payload without outcome63 knowledge, then use the explicit user-terminal handoff below to lock it. Do64 not invent missing events.657. Only after the process review is locked, record and independently resolve the66 outcome. Prepare the second-pass postmortem payload, binding67 `process_review_id`, the sealed DecisionSnapshot, and undisputed forecast68 outcome events, then hand it to the user for the terminal action below.69 Store any generalization as a lesson candidate, not as a durable rule.70 Separate knowledge-base integrity errors, decision process errors, and71 forecast resolution or calibration errors.728. Label lesson state as `candidate`, `corroborated`, `validated`, or `retired`.73 Record evidence origin separately as `historical_replay`,74 `historical_holdout`, or `live_forward`.759. Promote a lesson only after independent contrary-case review and out-of-sample76 evidence appropriate to its scope and regime. Dispatch the registered77 independent review role; its authenticated review principal must call the78 `promote_lesson` MCP tool. There is no direct CLI promotion path, and a79 caller-supplied role is not reviewer authentication. Historical replay80 evidence alone cannot become holdout or live-forward validation.8182## User Adoption And Terminal Handoff8384Never infer that the user adopted a Judgment. When the user explicitly chooses85to adopt one, prepare a payload with `judgment_id`, the user's decision, and an86optional superseded adoption reference. Codex must not run the adoption command87or write the event directly. Tell the user to run it interactively:8889```text90{{TRADINGCODEX_WORKSPACE_LAUNCHER}} decision adopt <payload.json>91{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem process-review <payload.json>92{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem create <payload.json>93```9495When an id is unknown and the structured MCP views do not expose the needed96record, hand off one read-only terminal command and ask the user to return its97output:9899```text100{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem list101{{TRADINGCODEX_WORKSPACE_LAUNCHER}} postmortem show <report-id>102```103104Never claim that a handed-off command ran until the user returns its output.105106## Boundaries107108- Do not treat LLM confidence, graph connectivity, retrieval frequency, or a109 profitable outcome as proof that a claim is true.110- Do not erase superseded claims or failed cases. Link replacements while111 preserving the earlier record and its decision-time context.112- Do not merge historical replay, historical holdout, and live forward metrics113 into one score.114- Do not silently change a strategy, skill, prompt, role, policy, approval,115 broker, or execution setting. Produce a reviewable change proposal instead.116- Do not replace a structured TradingCodex MCP operation with a launcher, shell,117 or direct file edit. User Adoption and postmortem handoffs are the explicit118 terminal-only exceptions.119- Do not draft, approve, or execute an order from memory evidence alone.120121Return the relevant artifact paths, the applicable strategy snapshot, the122strongest supporting and contrary episodes, lesson status, evidence tier, and123the next validation needed.