Conformance run against v2.3.22: twelve held, three not applicable - four questions on whether I mapped it correctly

[technomorphcorporation]

I maintain an open-source conformance suite - fifteen executable invariants that any system moving money is expected to hold, driven through a five-method adapter so it never sees the schema or the code.

I ran it against Formance v2.3.22 (pinned by digest) on two seeds. Twelve invariants held, three were not applicable, nothing failed. Published the result: Formance Report

Since I've published a document about your software, so I'd rather it be accurate. Four questions:

1. I used Idempotency-Key and deliberately not reference, because they behave differently. Which do you expect a payments team to use - and what happens to a reference when its transaction is refused, freed or spent?
2. Is there a per-entry hash chain exposed anywhere? I couldn't find one, so that check went unmeasured rather than guessing.
3. Two checks report not applicable because a posting is balanced and single-asset by construction. I only used postings, never Numscript - could a script express an unbalanced or multi-asset transaction, in which case should those be measured rather than skipped?
4. Does ?force=true genuinely mean 'allow this account to go negative', or does it bypass more than that? The mapping is in the adapter's javadoc, decision by decision. The one I'd most like challenged is ?force=true standing in for "allow overdraft".

Happy to link any response alongside the report, and to re-run on a version of your choosing.