A plan can be internally valid and still solve the wrong problem.
Suppose an optimizer returns a production schedule with no machine overlaps, correct setup time, and a better tardiness objective. A verifier can re-check every one of those facts and return green. But if a night-shift prohibition was omitted before the schedule was generated, the green result is about an incomplete rule set.
That is why Feasible does not ask one certificate to carry two different kinds of trust.
Certificate one: what rules exist?
The Rule-Pack Certificate describes the approved constraint universe. It contains the source-policy digest, formal rules, provenance spans, back-translations, a coverage ledger, conflict resolutions, the governing conflict policy, and the rule-pack digest.
Its verifier checks more than an Ed25519 signature. It reconstructs the rules, re-derives the rule-pack digest, recomputes coverage over the embedded source text, confirms the source digest, and deterministically replays the conflict policy.
That matters because signatures answer only “has this payload changed since this key signed it?” They do not answer “is this payload complete?” or “was this policy resolution applied correctly?” Those require domain checks.
The certificate states its ceiling explicitly: coverage is relative to the deterministic span enumeration and classifier. It is not a proof that no human or machine could ever discover another normative clause.
Certificate two: does this plan satisfy them?
The Plan Certificate embeds the instance, the active rules, and the proposed plan. Its verifier is solver-free. It reconstructs the intermediate representation, runs the polynomial checker against the embedded plan, recomputes the objective, re-derives the active-rule-set digest, and verifies that the visible body matches the signed canonical bytes.
This is stronger than checking the signature and trusting the claims printed beside it. Feasible’s adversarial suite modifies a plan, re-signs the bad body with an attacker-controlled key, and expects verification to fail because the checker finds the operational violation. A self-consistent forgery is still a bad schedule.
The plan certificate also labels where each claim came from: checker, solver, objective recomputation, ledger, signature, or rule-pack digest reference. Language-model output is not an allowed provenance source for a plan truth claim.
The digest is the joint
The Plan Certificate does not copy the entire governance history of the Rule-Pack Certificate. It binds to that universe through an immutable rule-pack digest and separately records which rules were active or dropped for this plan.
Verification with both certificates checks three identities:
- the Plan Certificate’s rule-pack reference;
- the Rule-Pack Certificate’s own re-derived digest;
- the expected universe digest.
If someone repoints the plan at a different pack, changes a rule, alters the active set, or edits a visible claim, the binding or signature check fails. The two artifacts can evolve independently without becoming ambiguous about which policy universe produced which plan.
What Feasible deliberately does not certify
The current optimality statement is narrower than the rest of the certificate. It reports “optimal per CP-SAT” with a same-engine tripwire. It is not an independently proven global-optimality result from a separate solver or proof checker.
Plan verification is also IR-relative: it proves the plan satisfies the approved formal representation. The source-to-IR edge is handled through coverage, provenance, back-translation, conflict governance, and a human gate. A semantic mistake shared by extraction, review, and checking can still survive.
Those ceilings belong in the certificate because hiding them would confuse tamper evidence with truth.
Why not combine the files?
A single large certificate would be simpler to demo and harder to govern. Every new plan would duplicate the policy universe. Every policy revision would muddy which schedules remain bound to the prior rules. Reviewers interested in policy would need to navigate plan data, while operations teams checking a plan would carry governance material they did not need.
The split creates two stable questions:
- Rule-Pack Certificate: “What exactly are the approved rules, and how were they accounted for?”
- Plan Certificate: “Does this exact plan satisfy the active rules, and are its claims intact?”
The digest between them is small. The trust boundary it preserves is not.