[MKuykendall]

This is a small experiment showing per-record runtime independent of the number of compiled obligations in a single-pass boundary execution model.

The demo focuses on behavior, not throughput tuning. Startup cost scales; runtime does not.

Details available under NDA. I’m reachable at: michaelallenkuykendall [at] gmail [dot] com

[refulgentis]

What’s a record, obligation, and boundary execution model?

[MKuykendall]

I did not expect a reply sorry!

A record is one unit of structured input handled by the system, such as a JSON document, an NDJSON entry, or an API request body. An obligation is a single requirement evaluated against that record, for example a field must be present, a value must satisfy a constraint, or a record must be accepted or rejected based on its contents.

A boundary execution model refers to evaluating those obligations at the system boundary where data enters, rather than deep inside downstream application logic. The intent is to make decisions as part of intake handling, before the data is handed off to other components.

:)