v13 "defrozen" — the result, reduced to what is real.
Chain: ontograph_v13.py -> conto_match_v13.py -> <model>.conto -> pykernel_v13.py
Claim (exact): zero specimen identifiers or class names are used as
EXECUTABLE PREDICATES in the three-file chain (audit_v13.py, exit-1
test); comments/docs may mention them. The kernel is profile-generic
across the evaluated models and the fixed journal schema.
Models declare their own execution profile (ProfileRole) and bindings
(BackendCode etc.); the compilers hold only patterns, the graph walk,
and refusals.
Verified here: both models compile (23/0/0, 17/0/0), contos byte-equal
to the prior record (removing the crutches changed no semantics), the
compact generic kernel executes both with structurally equivalent 21-row
journals (model-specific display vocabulary) and
asserted refusals — in-container.
Contained and evaluated: the CONTO-generated SQL realization, server execution, a
finished methodology. Those are described honestly elsewhere or are
future work.

Reproduce (CONTO first, output second):
  python3 conto_match_v13.py cofris12_case4_model.json -o case4_v13.conto
  python3 conto_match_v13.py cofris12_v12_model.json  -o v12_v13.conto
  python3 demo_case_v13.py case4_v13.conto /tmp/j1.md
  python3 demo_case_v13.py v12_v13.conto  /tmp/j2.md
  python3 scenario_asym_v13.py v12_v13.conto /tmp/asym.md
  python3 fixtures_refusals_v13.py
  python3 fixtures_v13_invariance.py
  python3 audit_v13.py

-- Simplified (expression-ground) model: cofris12s.json --
cofris12s.json removes line-level phases and Line Acceptance; the
Performance Fulfilled situation declares Q=ALL with the expression
Expr: RemainingQuantity=0 (compiled into EXPR; member derived as the
unique class DECLARING SemanticRole=RemainingQuantity: Line Item LER).
Regenerate:   python3 conto_match_v13.py cofris12s.json -o v12s_v13.conto
Fixture:      python3 scenario_simplified_v13.py
              (control 24 rows, asymmetric 18; no line phase rows;
               journal prefix preserved; foreign-ID invariant)
Web UI:       python3 seven_bonds_web_v13.py v12s_v13.conto
              open http://localhost:8018/?cid=C1
Screenshots in the paper were taken from this UI (headless Chromium,
DOM-asserted before capture). Row counts differ from the regular v12
tests (21/30) because line-level acceptance and phase rows are absent
by design. The journal table displayed by the UI is a projection of
the append-only Journal joined with UI-side account/context annotations
(Stock, Flow, Amount override, Due, Entity, Other party); only Journal
columns are ledger content. All fixtures refuse to run under python -O.

-- CONTO -> SQL generator (one source, one boundary) --
conto_to_sql_v13.py emits a T-SQL deployment from CONTO and only CONTO:
it parses the compiled file through the reference kernel's own bindings
(no model access, no name heuristics) and realizes Journal DDL, one
posting procedure per manifestation rule, the batch-use procedure with
its availability gate, and usp_RunCascade implementing the acceptance
engine (phase-form and expression-form grounds, leaf transition events,
triggering situations). Rules the kernel leaves dormant are disclosed
in a coverage footer inside the generated file.
Generate:   python3 conto_to_sql_v13.py v12s_v13.conto deploy_v12s_v13.sql
Verified here: every batch parses as T-SQL; every MF/PC/AC realized or
explicitly disclosed (all three models); foreign-ID conto produces
byte-identical SQL. Live-server acceptance: deploy deploy_v12s_v13.sql,
then run acceptance_v13_control.sql — it EXECs the control scenario and
THROWs unless 24 rows, three Fulfilled heads, Unconditional exercised,
and zero line-level phase rows, then EXECs dbo.usp_LoadContext to
display the case journal, availability, and positions — the SQL
realization's window, generated from CONTO like everything else. The
web UI drives the kernel realization only; pointing it at SQL Server
is a driver swap (v14). That live run is the defined next verification
and is yours to perform.

-- Realization equivalence (the thesis, executable) --
conto_to_sql_v13.py --dialect sqlite <conto> <runtime.json> emits the
same statements as an SQLite statement set; sql_driver_v13.py is a
generic executor with ZERO institutional logic and ZERO model
vocabulary (named statements, guard queries -> refusal codes, cascade
loop until fixpoint). scenario_equivalence_v13.py runs control and
asymmetric scenarios through the reference kernel and through the
generated statements: operational trace projections byte-identical for both models (15 journal columns; provenance-column parity is scheduled)
(v12s 24/18, baseline 30/21 rows), refusal parity (51222/51227/51203).
The web UI takes the backend as an argument:
  python3 seven_bonds_web_v13.py v12s_v13.conto                       # kernel
  python3 seven_bonds_web_v13.py v12s_v13.conto --sqlgen runtime_v12s.sqlite.json
Same operations, same journal, asserted. The T-SQL dialect is the same
emitter's server target; its live acceptance run remains yours.
