With MessageFoundry, your integration logic isn't buried in an engine's database. It's ordinary code in your own version-controlled repository — so every change is a reviewable diff, every change is tested by CI against the real engine before it ships, and rolling back is one git command. That's what makes a small team's interfaces dependable.
On most legacy engines, a channel's filters and transforms live inside the engine's own database. That has consequences teams feel for years.
Logic in a database blob is hard to diff, peer-review, or reason about. Changes land without the author, history, and review that other code gets.
"Someone changed it in the Prod GUI, and now Staging ≠ Prod." Without one source of truth, environments quietly diverge.
No commit-time gate means a broken route or a bad transform is often found in production — and rollback means restoring a database, not reverting a commit.
Connections, Routers, and Handlers are plain Python in your private git repo — scaffolded by messagefoundry init. The engine itself is a pinned, signed dependency your team installs but never edits.
One reviewed commit of that repo deploys to every environment; only a small per-environment values file differs, so Test can't drift from Prod. Git is the source of truth — and it carries no secrets and no PHI (those come from environment variables, never the repo).
messagefoundry init scaffolds a ready-made CI workflow in your repo. It runs on every pull request and every push to main, and the same gate runs in the VS Code editor and an optional pre-commit hook — so a green CI means a green desk.
Every config module imports and every inbound → router → handler reference resolves. A router named but never defined, a dangling binding, or an import error fails the build.
Synthetic messages route through the engine's real routing core — the same function production runs — with no store, network, or connectors. Green in CI means it routes identically in production; there's no separate test path to drift from reality.
Catches the environment / security-posture foot-gun that would make the engine refuse to start — at commit time, not at 2 a.m. on the Prod box.
Before install, CI verifies the pinned engine wheel's build provenance (SLSA / Sigstore). A swapped or relabelled wheel fails the build instead of shipping silently.
Make the gate a merge requirement on main: no interface change lands unless validate and dry-run are green and reviewed.
The exact same check runs in the editor as you work, in your pre-commit hook, and in CI on the PR — so problems surface early and consistently.
Interface logic gets the same rigor as application code: branch, pull request, review, merge — with CI exercising your routes on representative traffic first.
Every change has an author and a history; reverting is a git operation. Engine upgrades are a deliberate, pinned, one-line bump you can roll back.
Promotion is "merge to main, deploy that commit everywhere." Environments stay in lock-step because they run the same reviewed code.
The CI gate proves your config loads, wires, and routes representative traffic without error, using the production routing logic. It does not by itself prove that a transform's output matches a downstream system byte-for-byte — a transform can produce valid-but-wrong HL7 and still pass.
Output parity is a separate discipline, and MessageFoundry gives you the tools for it: a synthetic test corpus you build with messagefoundry generate, the standalone test harness (disposition coverage and fault injection), and a reconciliation window (golden in/out pairs, sent-vs-delivered) before and after cutover. We say this plainly because reliability you can trust is reliability stated honestly.
Scaffold a config repo with the CI gate already wired in, and run your first message in minutes.
