KYE-DGP-001
Runtime data governance for delegated AI actions.
Every time an AI agent reads, summarises, exports, trains on, shares, or discloses a row of your data, the KYE Data Governance Pack™ checks: is there an active manifest, does the purpose match, is the action permitted, is the classification supportable, is the residency allowed, is the retention window still open? Default-deny on every axis. One signed evidence row per access. Offline-verifiable.
The problem in one sentence
AI agents are now making thousands of per-day data-access decisions on behalf of your organisation. None of them carry the per-row, per-purpose, per-jurisdiction governance that your DLP, IAM, or warehouse access controls were designed to enforce when humans were the actors.
The KYE Data Governance Pack™ inserts a single data_use PDP stage between your existing state check and your existing rules evaluation. That stage loads the active data_use_manifest at decision-time and binds the requested action against it. If anything is missing, mismatched, expired, revoked, residency-violating, retention-exceeded, or classification-disallowed, the action is denied and the denial reason is recorded against a canonical reason-code dictionary.
The new PDP pipeline order
entity → authority → purpose → scope → state → data_use → rules → decision → evidence
Only one position changes: data_use is inserted between state and rules. The existing rules stage continues to evaluate the loaded rule packs unchanged; the new stage runs the data-governance-base + dsar-handling rule packs first so that downstream rule packs see the already-filtered set of admissible actions.
Backwards-compatibility: tenants without a data_use_manifest see the new stage as a no-op (the stage emits a single advisory manifest_missing obligation and falls through). The default-deny posture activates the first time a tenant publishes a manifest covering an asset.
What ships in V1
18 artefacts, fully canonical, decision-locked in constitution/31-DATA-GOVERNANCE-PACK.md.
4 schemas
kye.data_use_manifest.v1— what data may an actor touch, for what purpose, under what restrictions, for how long. Signed Ed25519. Carries GDPR Art. 6 + Art. 9 lawful_basis, residency allow-list, transfer safeguards, retention policy.kye.data_asset.v1— declarative asset record for db_table / object_store / api / ckan / topic / vector_collection / file. Carries per-field PII inventory with redaction strategies + data_subject_ref_field for DSAR matching + lineage_parents for snapshot reconstruction.kye.data_access_evidence_event.v1— per-decision evidence row recorded by the data_use stage. Carries data_subject_ref (SHA-256 hashed; raw value never in chain) for DSAR matching without full audit-chain scan.kye.dsar_evidence_pack.v1— signed DSAR output bundle (GDPR Art. 15). Deterministic evidence_rows ordering → byte-stable content_hash.
185 dictionaries
data-classification— 6 terms (public / internal / confidential / personal_data / special_category_data / financial_data) with control_refs to GDPR / PCI DSS / HIPAA / PSD3 / DORA + default_retention_days defaults.data-purpose— 12 canonical purposes with lawful_basis alignment to GDPR Art. 5(1)(b) + OECD purpose-specification principle.data-action— 10 action verbs (read / summarise / export / train_model / share / transform / disclose / delete / anonymise / redact) with severity tiering.pii— 23 PII types across 4 categories (identifier, regulated_identifier, financial_identifier, special_category, behavioural) with GDPR Art. 9 / HIPAA / PCI cross-walks.privacy-reason-codes— 16 denial codes used by data-governance-base + dsar-handling.
57 rule packs (12 rules total)
data-governance-base— 7 rules: manifest-missing-or-expired, purpose-not-authorised, action-not-authorised, training-without-explicit-purpose, classification-mismatch, residency-violation, retention-exceeded. Default-deny on each axis.dsar-handling— 5 rules: subject-ref-matches (include candidate), below-inclusion-confidence (exclude), classification-excluded (exclude), redact-third-party-fields, require-signed-pack (assembly-completion gate).
1 PDP stage extension
data_use— inserted in the canonical PDP pipeline betweenstateandrules. Resolves the active manifest at decision-time, binds the action, emits one kye.data_access_evidence_event.v1 row per access.
1 bounded agent
kye-dsar-evidence-agent— storage-agnostic library + Worker shell that assembles DSAR Evidence Pack™s from per-tenant audit-chain entries. Same canonical agent pattern as kye-ops-agent and kye-training-agent.
Cross-walked to the frameworks you already report against
Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.
| Framework | Control row | Coverage |
|---|---|---|
| GDPR | Art. 5(1)(a) lawfulness | partial — via action_not_authorised |
| GDPR | Art. 5(1)(b) purpose limitation | full — purpose_not_authorised |
| GDPR | Art. 5(1)(e) storage limitation | full — retention_exceeded |
| GDPR | Art. 5(2) accountability | partial — manifest_missing + signed evidence |
| GDPR | Art. 9 special-category lawful basis | partial — classification_mismatch when basis absent |
| GDPR | Art. 15 right of access (DSAR) | full — dsar_evidence_pack.v1 |
| GDPR | Art. 15(4) third-party rights | full — dsar_redact_third_party_fields |
| GDPR | Art. 22 automated decision-making | partial — training_not_authorised |
| GDPR | Chapter V cross-border transfers | partial — residency_violation |
| UK GDPR | IDTA cross-border | partial — residency_violation |
| UK DPA 2018 | Pt 3 Ch 3 subject access | full — dsar_evidence_pack.v1 |
| EU AI Act | Art. 10 data governance | partial — training_not_authorised |
| EU AI Act | Art. 12 automatic logging | partial — signed evidence row per access |
| DORA | Art. 6 ICT risk | partial — manifest_missing audit chain |
| HIPAA | 164.514 de-identification | partial — pii dictionary + special_category_data |
| PCI DSS | 3.2.1 / 3.4.1 cardholder data | partial — financial_identifier handling |
What this pack is not
You get a precise, signed answer — every claim below maps to a canonical artefact you can verify against the open contract.
- Not a discovery scanner. V1 ships the dictionary; the PII scanner is V1.5, gated on first paying customer pull. Inventory your assets manually (or via your existing tooling) into kye.data_asset.v1 records; KYE™ governs them at decision-time.
- Not a Purview / Collibra / Alation replacement. Those are data-catalogue + lineage + stewardship systems for human-led data analysis. KYE™ governs delegated agent data actions at runtime. They sit side-by-side; KYE™ can read asset metadata from your catalogue (V1.5 connector hooks).
- Not a DLP appliance. KYE™ governs at the action API; DLP governs at the network egress. Different cuts of the same problem; complementary, not competing.
- Not sector-specific. V1 ships
data-governance-base. Sector rule packs (GDPR-EU, Healthcare, Financial-services, Public-sector, AI-training, Cross-border) are V1.5, each gated on the first paying customer in that sector. - Not multi-tier in V1. One SKU at £150k/year. V2 may introduce a regulated-data variant only on ≥3 enterprise asks.
Get started
Every claim here is backed by the open KYE Protocol™ contracts and verifiable end-to-end from the publisher's JWKS — you check it yourself, you don't take our word for it.
- Read the DSAR capability page →
- Apply for a Data Governance Pack engagement → —
KYE-DGP-001at £150k annual, includes scoping + first manifest + first DSAR rehearsal. - Browse all 57 rule packs →
- Regulator probe playbook → — how the same offline-verification posture extends to DSAR Evidence Pack™s.
- Browse the reference manifest example on GitHub ↗