- what ships
- 4 control packs, 27 controls
- what a pack is
- a reading of a law, published as data
- what it certifies
- nothing
- the check
pistra audit verify
What a control pack is
A control pack is one reading of a regulatory regime, published as data. It carries guardrail and access rules that cite the regime's controls, a rule suite that proves what those rules decide, and a page naming what it does not cover. pistra pack add copies the rules into your deployment document. After that the document is yours and the pack is not consulted again: there is no pack mode at runtime, and nothing reads a pack while a request is being decided.
The identifiers a rule cites ride onto every audit record that rule decides, so a decision can be found later by the control it served. The gateway carries those identifiers and never reads them. The framework and its taxonomy stay yours, which is why a pack can be corrected without touching the binary.
What a pack does not claim
A pack certifies nothing.
It is one reading of a published text, and the reading is the pack author's. Every control carries the citation it was read from, so the reading can be checked against the law rather than taken on trust.
No page here says pistra satisfies an article. A rule enforces what it enforces, the record says what it decided, and whether that meets a control is the assessor's finding to make.
Where the rules come from
A control identifier is an opaque string the gateway carries and never reads, so the simplest route needs no pack: put your own framework's identifiers on your own rules, and every decision those rules make carries them onto the record. Take a shipped pack when somebody has already read the text you are held to. Write one when the regime is not among those read, or when several deployments in one organisation should decide the same way without rules being copied between documents.
A pack of your own is a directory of four files, added exactly the way a shipped one is and held to the same checks before anything merges: every rule cites a control the pack declares with a citation, the fragment compiles the way the gateway compiles it, and the suite passes. It can name a shipped pack in depends and attach its own identifiers to rules that pack already carries, so one rule decides once and the record names both regimes.
The regimes read
A pack exists for a regime once somebody has read the text and written the rules, so this list grows and is never the measure of what the mechanism can carry. Today it is 4 packs citing 27controls, adding 11 rules and pointing 12controls at the mechanism that addresses them where no rule can. Each pack's page lists every control it cites, every rule that cites one, and what the pack leaves to you.
| Pack | Regime | Controls | Rules |
|---|---|---|---|
sa-pdpl | Saudi Personal Data Protection Law | 5 | 4 |
sa-ndmo | NDMO data classification | 10 | 4 |
sa-sama-csf | SAMA Cyber Security Framework | 6 | 2 |
sa-sdaia-ai | SDAIA AI ethics and generative AI guidelines | 6 | 1 |
The packs are licensed under the Apache License 2.0, and the rest of pistra is not. A reading of a law is more useful to everyone if anyone can take it, correct it and publish the correction.
What an assessor asks for
The question is always some form of show me what happened, and the answer is a record rather than a report. Every access and guardrail decision is written to a signed record: the key that made the request, the rule that decided, the controls that rule named, and the spans a redaction rewrote. Admitted requests are absent on purpose, so the trail is decisions and not a copy of your traffic.
- Every decision under one control. The identifiers a rule cites are a field on the record, so the trail answers which decisions served a control without anybody parsing bodies to find out.
- Signed where it was decided. Each record is signed by the node that made it with an ed25519 key, and chained to the record before it.
pistra audit verifychecks every chain: each record hashes to its entry, each entry links to the one before, each is signed by the key its chain started with, and no sequence number is missing.- It runs where you are. The check reads an exported trail and trusts neither the gateway nor the store it came from. Exit status is 0 when every chain verified.
- A trail cut short is a finding. Give
verifythe heads the cluster witnessed and it reports a trail that stops before them. - The rules were proved before they shipped. Each pack carries a suite run against its own rules, so what a rule decides is a test result and not a description.
What this does not do
- A pack is not an assessment. The reading is ours and the review is yours. Nothing here has been submitted to a regulator, and no regulator has reviewed it.
- A pack is only a regime somebody read. The list above is what has been written, not what the mechanism supports. Nothing here waits on us: a control identifier is an opaque string, so your own framework's identifiers ride on your own rules today, and a regime nobody has read is a pack you write.
- A pack covers what a gateway can see. Classification of documents, registers of information assets and data catalogue entries stay with the entity. Each pack's page names its own share of this.
- Evidence is of decisions, not of coverage. The trail proves what the gateway decided. Whether every call reached the gateway is a different question, answered by the second ledger and never by this one.
- A signature attests the record, not the decision. The chain proves a record was not altered, removed or reordered after it was written. That the node was honest when it wrote it is a different claim, and it rests on the host. Threats and limits says what that costs.