Policy packs
A policy pack is a machine-readable rule set, written from a published text. It grades a verified record rule by rule, and each rule answers compliant, non-compliant or indeterminate, next to the clause it encodes.
A pack is evaluated only against a record that has already been verified: well formed, signed, and signed by a key the verifier's trust store trusts. Each rule then answers on its own, and the pack's finding follows from the rules that carry weight.
Only the mandatory rules decide a pack's finding. A recommended rule that fails is reported and does not, on its own, make a record non-compliant. A rule that cannot be answered from the record in front of it answers indeterminate rather than guessing.
A pack reads what a record declares. It cannot check whether a declaration is true, whether a document pinned by hash is adequate, or anything outside the record. The issuer's own declaration and this verifier's finding are always shown as two separate statements, never merged, so a disagreement between them is visible rather than resolved silently.
A pack's result is not a legal finding. It means the pack's mandatory rules passed on what the record declares: one reading of a text, written by people who are not your regulator and not your lawyer.
Published with the standard under Apache 2.0. Each one is KHALM's own reading of the text it cites, published under KHALM's name as its authority: no regulator, standards body or notified body authored, endorsed or reviewed them. Their ids say so — khalm-reading-eu-ai-act-2026, and so on for the rest.
They carry no signature. A pack's author may sign one, and a verifier tells you whether anybody did and whose key it was, so a signature is something you check rather than something you assume.
What a record can answer from the AI Act: that its lineage is kept and ordered, that what was learned and the environment it was learned in are pinned, that the issuer signs with an attested key, and that the documents the issuer relies on for data governance and human oversight are pinned by hash.
The subcategories of the MAP and MEASURE functions that ask for documented, checkable evidence about an AI system and the technology it was built from.
The Annex A controls that an artifact can answer: event logs and data provenance, technical documentation, and suppliers.
The C2PA content-credentials model applied to the model itself: a claim signed by a credential a relying party can check, and what the claim is about bound to it by hash.
Runtime attestation evidence, as a reference profile of the RATS architecture: the environment named and measured, the evidence integrity-protected and linked, and the attester identified by a key a verifier can evaluate.
The pack format is part of the open standard, with its own schema, so a pack is not something only KHALM can write. An organisation with its own rules — an internal policy, a customer's requirement, a sector's code — writes them as a pack and grades records against it, with no change to the record format and no permission from anyone.
That extends to authority. A regulator, a notified body, an auditor or your own compliance team can publish a pack, sign it, and have people trust their key rather than KHALM's: a trust store carries policy authorities for exactly that. Whose reading of a text you grade against is your choice, and the reference packs are only the reading KHALM offers.
Signing a pack is part of the open format and free, and stays free. There is no command for it yet: today an authority signs a pack with its own code, from the published format, and a vmr command for signing and for checking a pack's signature on its own is planned. KHALM's own five carry no signature, so a verifier reports none for them.
A worked example, graded against all five: a record for a model KHALM fine-tuned, with the model itself published, so you can hash its files and check the record rather than take the result on trust.
The format, its schema and the five reference packs are published under Apache 2.0, with a guide to writing your own.
