Allowed is not verified: five-day Evidence Pack review

[sev7enITA]

Allowed is not verified

From 13 through 17 August 2026, run one synthetic AI case locally and challenge whether its evidence supports a real human decision.

Start here: Open the 10-minute PALO Evidence Pack

Release: PALO v3.0.1 Evidence Pack Activation

The case is synthetic, runs without an account and sends no mandatory telemetry. The optional local receipt proves schema checks and digest binding only. It is not certification, legal advice, independent assurance or deployment authorization.

Allowed is not verified. Tell us where the dossier fails to support the declared outcome.

Choose one bounded review task

• Automation builders: finish the preloaded case, prepare one case contribution, and report completion time, one friction trace and one possible workflow bypass.
• Policy-as-code and platform security: attempt receipt tampering, missing-authority and fail-open paths; return one reproducible negative test with severity and expected behavior.
• Governance, legal and audit: assess whether the dossier supports a named human decision without overstating legal status; return one decision-rights review and one evidence-quality correction.
• Research and standards: reproduce the result from a clean clone and critique claim/source traceability; return a reproduction record, source critique and one measurement improvement.
• Executive and design partners: decide continue, pause or stop using only the dossier; return the decision, missing evidence and whether you would repeat with a second case.

Use synthetic or safely publishable material only. Report vulnerabilities privately through the security policy, not in this Discussion. Participation does not imply endorsement, partnership or affiliation.

Accepted, rejected and deferred decisions will be recorded in the public changed-because-of-feedback log. Bounded implementation work is tracked in the 12 activation issues.

The GitHub Pages link above is the current v3.0.1 front door. paloframework.org is hosted separately on Hostinger and will show the same build after the verified release bundle is uploaded and its cache is purged.

[Poke-nushi]

Hi Fabrizio — I reviewed PALO at 2208e316 and found one lineage question where an owner-level classification would help.

In core.js, GovernanceRuntime.verifyAction() calls normalizeActionClaim() before invoking the enforcement provider; normalization recomputes the digest of canonical action.arguments. Against VATE's three-case review slice, I see this only as an ordering analogue: the VATE mismatch concerns a referenced request artifact, so the digest subjects differ.

PALO's AGT adapter maps transform to denied and requires a new Action Claim. VATE attenuation instead records original/effective request hashes in one admission receipt. For an allowed 1.2 replacement on the full-cycle path, the later capability/receipt/outcome chain is created for the replacement.

Does PALO define a typed predecessor/successor relation between the denied Action Claim and its replacement, so the replacement's execution chain remains traceable to the original proposal? The Atomic Evidence Claim can target agentic-execution, but supersedesClaimId is typed as another evidence-claim-* ID; I have not treated it as Action Claim lineage.

“Intentionally outside the current model,” “deployment-specific metadata,” or a source pointer would each fully answer this.

[sev7enITA]

Dear Takao, thank you for the careful review. Your reading is correct at 2208e31.
PALO does not currently define a typed predecessor / successor relation between an AGT-transform-denied Action Claim and the replacement Action Claim. I classify that relation as intentionally outside the current normative model, with only deployment-specific correlation available.
The AGT adapter denies transform and emits the obligation to submit a new digest-bound Action Claim: if that replacement is later allowed, its capability, receipt and outcome-attestation chain binds only to the replacement claim and digest.
A deployment may carry the predecessor claim ID / digest and AGT decision reference in the replacement Action Claim’s metadata. Because metadata remains part of the normalized Action Claim, those values are bound by the replacement’s claim digest. However, the current schema and runtime do not assign standard semantics to them or validate that the referenced claim exists, was denied because of transform or produced the replacement arguments. I therefore would not describe this as portable PALO lineage.

You are also correct about the Atomic Evidence Claim: supersedesClaimId relates only evidence-claim-* records. An agentic-execution target does not turn it into Action Claim lineage. So the direct answer is: no typed Action Claim lineage at this revision. The original and replacement can be correlated at deployment/case level, but standardizing transform provenance would require an Action Claim or decision-contract extension.

Thank you so much!

Fabrizio

[Poke-nushi]

Thank you, Fabrizio — this fully resolves the lineage question.

At 2208e316, I’ll record that PALO has no typed Action Claim predecessor/successor relation; that relation is intentionally outside its current normative model. Replacement-claim metadata may carry the predecessor claim ID/digest and AGT decision reference, and those values are covered by the replacement claim digest. The current schema/runtime does not assign them portable lineage semantics or validate the referenced claim’s existence, transform-deny origin, or replacement-argument derivation. The later capability/receipt/outcome-attestation chain binds only to the replacement claim/digest, while supersedesClaimId remains scoped to Atomic Evidence Claims.

For the VATE comparison, I’ll therefore keep PALO’s immutable Action Claim → new Action Claim path distinct from VATE’s original/effective request binding within one admission receipt. Thanks again for the precise classification.