An owned product built around a recorded decision before a software action. This case describes the product architecture and its public implementation.
Why the record comes first
Software can change a price, route a request, or grant access in one step. A later review needs to explain which inputs and rules allowed the change.
Decide puts a recorded decision before the action. The application can retain that result alongside the work it performs, with a reason and a policy version to inspect.
How the product is structured
The public surface connects a Decision API, developer documentation, and verification. A production decision uses a versioned declarative Rulebook v1.
An application supplies structured facts directly, or uses a registered trusted adapter to normalise facts before the same rulebook evaluates them. The rulebook selects the verdict; the application owns its permitted action.
The Decision Record carries request and decision identifiers, the rulebook version, a reason, evidence, and input and output hashes. Replay and verification let a developer inspect the recorded result.
The documentation connects the initial API request to record storage, outcome handling, and the verification path. Krafthaus shows how this layer fits into an approval workflow and a named handoff.
Where the authority stops
AI-assisted recommendations remain advisory. A confident answer does not become a binding production verdict. Customer executable policy code is outside Rulebook v1.
A record does not independently prove that the caller's business facts were true. An approval also does not prove that the downstream action completed. The application must preserve both the decision and what happened next.
