From a policy PDF to a rule you can trace.

A familiar gap between policy and code

A policy says that approved suppliers must hold a current certification. The operations team adds a checkbox to a spreadsheet. A developer checks that the certification field is not empty. A reviewer later discovers that an expired document still passes. Everyone implemented a plausible interpretation, but nobody recorded a shared one.

The problem starts before the code. “Current certification” needs a definition: which certification, what expiry rules, which exceptions and what evidence? A traceable rule makes those decisions visible rather than leaving them inside separate implementations.

Give the rule a stable identity

Start with an identifier such as SUP-014 and a short title: “Approved suppliers must have a valid certification.” Keep that identifier stable as the wording changes. A document filename or a spreadsheet row number is a weak substitute because it can move independently of the rule’s meaning.

Record the owner and the current status. Draft, in review, approved and deprecated describe different commitments. A draft is a proposal; an approved version is the one an implementation should reference. Replacing it silently destroys the distinction.

Attach a precise source

“Supplier policy” is a starting point, not a complete source reference. Add the policy version, section, relevant paragraph and effective date when available. Preserve enough context for another person to understand the requirement without reconstructing your research.

If the rule comes from a business decision rather than a formal document, link the decision and its approver. Do not invent an official source just to fill a field. An honest gap is easier to resolve than a reference that suggests more certainty than the evidence supports.

Resolve the interpretation before approval

Ask what “valid” means at the time the check runs. Does a certification expiring today count? Which timezone applies? What happens if the issuer withdraws a certificate before its printed expiry date? These questions may need different answers in different workflows.

Write the agreed interpretation and representative examples. Have the domain owner review it. Technical reviewers can then check whether the proposed implementation preserves that meaning. Human approval is a decision record; a green test result cannot replace it.

Connect the rule to an implementation

Once approved, connect the rule version to the SQL check, API validator, local test or manual review that applies it. This link is useful even when the implementation is not generated automatically.

Policy version 2 · section 4.2
  → SUP-014 · version 1.2 · approved
  → supplier-certification check
  → execution result for a specific delivery

This is an illustrative chain, not a claim that a particular product already maintains it. The practical aim is to answer two questions: which rule was intended, and which check actually ran?

Keep evidence tied to the version

A result saying “passed” is incomplete without context. Record which input was checked, when the check ran and which rule and implementation versions it used. Retain only the evidence needed for your workflow, with access appropriate to the underlying data.

When the policy changes, compare the approved rule versions and identify affected checks. A change may require new examples, a different severity or a transition period. Deprecate the old version explicitly so that historical results remain understandable.

Start with one policy and a small rule set

Choose one document and a manageable set of requirements. Give each a stable identity, source, owner, review status and implementation link. You will quickly find ambiguous terms, duplicate checks and requirements with no operational coverage.

This is the problem behind the RuleGenius project: a shared home for rules, their context and their path to execution. The project is in development, with human review and traceability at the center. To discuss a real policy workflow, talk to Minibota Labs.