Task: Round trip the credit simulation configuration

Table of Contents

This page documents a task in the Model the ORE report configuration as entities story. It captures the goal, current status, acceptance, and any notes or results.

1. Goal

This file carries the smallest complete example of a repeated value row, the transition matrix cell, so it is where that shape is settled for every other document.

2. Status

Field Value
State DONE
Parent story Model the ORE report configuration as entities
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-27

3. Acceptance

  • Every creditsimulation.xml in the corpus imports, exports and matches.
  • A transition matrix has one row per cell, keyed to the matrix and the two states, so the matrix is reproducible.
  • An entity references its transition matrix by foreign key, not by name in a text column.

4. Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

5. Measurements

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

What Value Command Commit
corpus files of this kind 14 `find external/ore/examples -iname "creditsimulation*.xml" \ wc -l` abff31c9f0
distinct documents behind them 7, each appearing twice `find external/ore/examples -iname "creditsimulation*.xml" \ sort \ xargs md5sum \ sort \ awk '{print $1}' \ uniq -c \ sort -rn` abff31c9f0
matrix cells per document 64, an 8x8 grid `.audit/ore-taxonomy/grid_check $(find external/ore/examples -iname "creditsimulation*.xml")` f8c9d3e538
state labels per matrix 8, identical in every file same command f8c9d3e538
grids that survive parse, format, parse 14 of 14 same command f8c9d3e538

6. Notes

7. Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

8. PRs

PR Title
#2307 [reporting] Model the registry and round trip a credit simulation

9. Review

Comment summary File Decision Notes
       

10. Result

All fourteen credit simulation documents in the vendored corpus round trip in memory, and one of them now round trips through PostgreSQL as well: parsed, mapped into the analytics entities, written through the generated repositories, read back, and exported. Five tables hold the content, including one row per matrix cell and one row per netting set, so the lists ORE writes as text in an element are rows here.

All tests passed (429831 assertions in 551 test cases)

Four defects were found by building and running rather than by reading. The generated repositories were never compiled because codegen does not add a new entity to the component file lists; the state comment was compared over an empty vector, so fourteen files passed a check that never ran, and an assertion about the comment was unsatisfiable because the binding strips comments on load; and the netting set ids were dropped on the database leg because no column stored them. Each is recorded in evidence/ beside this task.

The export deliberately does not write ORE's state comment back: the rating names are held by the type, and the difference is asserted rather than compared away. Whether ORE itself accepts the exported document is not tested.

Note the mapping runs over a model that predates the row type: map() throws unless a matrix is eight by eight, which every corpus document is.

Emacs 29.3 (Org mode 9.6.15)