limitations to the section it produces — data gaps that are a property of the platform’s schema, not of a particular period’s data, and so are printed in the document itself regardless of whether that section found any records. Three of them are permanent as of this release. This page states them plainly, separate from the document, because publishing them here is consistent with the feature’s own premise: an audit document that hid its own gaps would be worse than one that names them.
1. No PII category field on guardrail executions
Zespan records that a PII guardrail passed, blocked, warned on, or redacted a check — but not a structured category of what kind of personal data triggered it. The detection reason is stored as free text only. The Guardrail outcomes section of a generated document reports counts by outcome, not by category of personal data, and states this limitation verbatim wherever it appears:“Zespan does not record a structured PII category for guardrail decisions. The detection reason is stored as free text only, so this document reports how many checks a PII guardrail passed, blocked, warned on or redacted, and does not report a breakdown by category of personal data. No category breakdown should be inferred from these counts.”
2. No agent-attribution on guardrail executions
A guardrail execution record doesn’t carry the identifier of the agent whose call it was checking. For an agent-scoped Compliance Card, the Guardrail outcomes section reports counts for every guardrail that applies to the requested scope by its agent filter, aggregated across the whole project for the period — not counts that are truly isolated to that one agent’s traffic:“Guardrail execution records do not carry an agent identifier. Counts above are for the guardrails that apply to the stated scope, aggregated across the whole project for the period.”
3. No member.removed writer
Zespan’s audit-event schema defines a member.removed action, and the CC6.1 access-control collector already includes it in its query — but no code path in the platform currently writes it. A member removal during the period is therefore invisible to this section today, and the document says so rather than letting an empty result be misread as “nobody was removed”:
“Zespan defines a member.removed audit action but no code path currently writes it. Member removals during the period are therefore not represented in this section. Absence of removal events must not be read as evidence that no member was removed.”
Because the collector already queries for member.removed, this becomes accurate automatically the day a writer for that event is added — no change to the evidence pack code is needed.
Where these show up
All three appear in thelimitations array of the relevant evidence section, rendered under Limitations of this evidence beneath that section in the HTML document, and as the limitations field of the corresponding section object in the JSON document. They print whether or not the section found any records for the period — a limitation is a property of what Zespan can observe, not of what happened to be true in a given month.
Next steps
- Evidence packs — where these limitations appear in a generated document
- Frameworks and controls — the CC6.1 control the access-control limitations belong to
- Audit log — what does, and doesn’t, get written to the audit log today