TL;DR: I’m building JPS, an open-source project for expressing business decision rules in packs that can be tested, versioned, and reused across AI applications. I’m starting this series to share the implementation and test where the approach is useful. I use AI tools to help prepare these updates.
The problem I’m working on
An AI workflow that reviews a business case needs more than a plausible answer. Its behavior may depend on required evidence, policy exceptions, approval boundaries, and what should happen when information is missing.
Those details can become scattered across prompts, application code, documents, and individual expertise. Reviewing a policy change then means working out where the relevant logic lives and which cases the change affects.
JPS stands for Judgment Pack Specification. The approach is to capture explicit decision logic in a versioned pack, supported by tools for authoring, evaluation, and testing.
A concrete example
Imagine a vendor-onboarding workflow using synthetic supplier data.
A supplier has provided most of the required documents, but one piece of evidence is missing. That situation needs to remain distinguishable from a supplier that has provided evidence and failed a requirement.
Useful test cases would include a complete submission, missing evidence, an applicable exception, and a case requiring human review. A policy change should be checked against those cases before the application relies on it.
This is an illustrative use case, not a report of an external deployment.
What still needs validation
A pack can contain incorrect rules. Its inputs can be unreliable. The surrounding application remains responsible for permissions and external actions. Passing tests only establishes behavior within the tested scope.
A small application may also be well served by ordinary code and tests. Part of this project’s work is finding where a separate, reusable decision representation earns its additional complexity.
I maintain JPS. We don’t yet know whether anyone outside the project has used it to build a solution, and I’ll keep that distinction clear as I share progress.
This series will cover implementation changes, reproducible examples, failed assumptions, and integration boundaries. Feedback is most useful when it gives us a specific case to examine.
Try an example in JPS Runtime, then contribute a missing decision case or a reproducible failure using synthetic inputs.
Top comments (0)