Data Classification: Decide Using Purpose and Evidence
Jump to section
Four tasks: hold three, narrowly allow one
You need to prepare a short summary using AI. Is it enough to know that the text is public or that you removed a name? As an employee or team lead, you need to assess a specific task: which data, for what purpose, in which environment and for whom. These four cases help you practise a decision you can explain and pass to an internal approver. Three tasks stay on hold; one has evidence for a narrowly defined permission.
The organisation Javor, its policy J-1, the tool Lupa, all records, permissions and evidence in this lesson are explicitly FICTIONAL. They are neither a vendor recommendation nor a real approval. Work only with the lesson text and your own local notes, without running AI, another tool, a browser or an external service. Do not upload anything. Do not look for real documents, personal data or credentials. The sample prompt below is a worksheet to read and complete by hand.
The organisation defines the class; the whole context determines permission
Each organisation defines its own classes, their meaning and the responsible roles. The four labels here are a teaching example, not a universal standard or a legal test. Fictional policy J-1 uses V — public, I — internal, D — confidential and P — strictly protected. V means material intended for publication; that class alone does not authorise every purpose or AI environment. Check the context, usage rights and intended audience for the result as well.
Worksheet — manual simulation only; do not send to AI.
Javor, policy J-1, Lupa, the evidence and data A–D are FICTIONAL.
Use only the information below. Do not look anything up, invent approvals or perform a
task in a tool.
J-1: V = public, I = internal, D = confidential, P = strictly protected.
A record that can be linked back to a person belongs to D here, even after renaming.
Six required gates: class in this environment; purpose and audience; usage rights; a
valid applicable contract; retention and deletion; access and settings.
Mark each gate YES / NO / UNKNOWN (missing evidence). Any NO or UNKNOWN => HOLD. ALLOW
(the defined task only) requires six YES answers. Do not fill UNKNOWN with a guess or
vendor documentation.
Fictional Lupa evidence card F1, revision 1, valid only in this simulation:
Evidence O-F1/1: internal approval by the data owner and security for V only, a
one-sentence internal summary, audience: the Javor team. Analyst-role account in the
Javor workspace, with no additional integrations.
Evidence S-F1/1: the contract administrator confirmed a valid contract for F1, this
purpose and class V, including all addenda required by J-1.
Evidence R-F1/1: verified settings and contractual commitment — inputs, outputs and
operational logs containing content are retained for no more than 24 hours, then
deleted; no backups containing content. J-1’s limit is 24 hours.
Evidence P-F1/1: verified access limited to the analyst role and recipients on the Javor
team; the provider has no access to content, training on content is disabled, and
there is no further sharing. J-1 requires these conditions.
Fictional Lupa evidence card F2, revision 1: O-F2/1 covers I and the same
purpose/audience, conditional on satisfying every gate; P-F2/1 documents the same
access conditions as F1. Contract evidence = UNKNOWN; retention and deletion =
UNKNOWN. F1 does not establish F2’s conditions.
A: “Person A, the only night-shift restorer in the village of Hvozdná Lhota, shift 17.”
Everything is invented, but the combination of role, place and shift would allow the
record to be linked to a person in the scenario. Request: a one-sentence internal
summary for the Javor team in F1. The owner’s U-A/1 evidence confirms rights to this
internal summary; it does not authorise a class change. Other F1 evidence applies only
within its own scope.
B: public invitation “Javor Workshop Day”. Fictional terms U-B/1 permit reading only;
they do not permit use for profiling. Request: create a visitor profile in F1 and
actually deliver it to a public audience instead of an internal summary. The text
establishes neither additional rights nor internal approval for that purpose.
C: “Paper model trial: three steps.” Internal instructions, class I, with no information
about people. Request: a one-sentence internal summary for the Javor team in F2. U-C/1
establishes rights to this use. Contract and retention remain UNKNOWN.
D: “The paper model has three parts.” Public catalogue text, class V, with no
information about people. Request: a one-sentence internal summary for the Javor team
in F1. U-D/1 establishes rights to this use, and O-D/1 confirms that this text,
purpose, audience and environment fall within O-F1/1. All F1 evidence is applicable.
For EACH case A, B, C, D, complete:
Case | class and reason | purpose, environment and audience | six gates with evidence
references | ALLOW/HOLD | reasoning | missing evidence (or none) | next internal
approval step.
Distinguish a known mismatch, NO, from an unproven condition, UNKNOWN. For ALLOW, state
the permission’s limits and who assesses a change. Your output is a draft decision
record; it grants no approval by itself.
I — internal: under J-1, for example, unpublished working instructions with no information about people. D — confidential: here this also includes a record that can identify someone from its context, not just from a name. P — strictly protected: J-1 uses this for secret credentials and especially sensitive records, for example. Do not add any real examples of those records to the exercise. Another organisation may use different labels, scopes and permitted processes; its data owner confirms the classification under its own policy.
Class is the first gate, not the entire decision. Ask: Is this class allowed in the exact environment? Are the purpose and audience approved? Do we have rights to this use? Is there evidence of a valid contract for the relevant service variant and any required addenda? Do we know how inputs, outputs, logs and backups are retained and deleted? Have access and required settings been verified? Evidence outside its scope does not establish a condition; if you have no other applicable evidence, record UNKNOWN.
An enterprise label, a “no training” claim or self-hosting does not replace these gates. Vendor documentation describes a service; it does not establish your organisation’s internal approval, your usage rights or the validity of your particular contract. Nor should you infer a ban from the class name alone: policy and applicable evidence determine whether this task is permitted. Self-hosting still requires decisions about access, retention and responsibility. This lesson does not assess a particular product or a real organisation’s legal compliance.
J-1 decision rule: six evidence-backed YES answers => ALLOW for the described task only. Any NO, or UNKNOWN for missing required evidence, => HOLD. HOLD means pause the intended use and refer the question to the responsible internal role; it is not an automatic ban on all AI. A tool’s benefits or high rating cannot compensate for a missing gate.
Four cases and two evidence cards
The worksheet contains the complete fictional set A–D and cards F1/F2. O documents the internally defined use, U the rights to the data, S the contract, R retention and deletion, and P access and settings. Revision and scope are part of each evidence item. F1 has complete evidence for class V and a one-sentence internal summary for the Javor team. F2 documents the scope for I and access, but lacks contract and retention evidence. Do not borrow those from F1. F2’s conditional scope for class and purpose is not yet permission to perform the task.
A: replacing a name with “Person A” is renaming, not evidence of anonymity. Under J-1 the invented record stays in class D because its context allows it to be linked back to a person. F1 allows only V: class gate = NO; A = HOLD. U-A/1 establishes rights and the purpose matches, but F1’s contract covers V only, so contract evidence for D = UNKNOWN. F1’s retention and access evidence is available. What is missing: contract evidence for D and internal authorisation of D in F1; renaming supplies neither. Next step: the data owner and security assess identifiability and a permitted route; the contract administrator assesses any applicable contractual scope. Do not process anything while that remains unresolved.
B: public invitation, class V. B = HOLD. Class YES: O-F1/1 covers V. Purpose NO: public profiling and delivery fall outside the approved internal summary. Rights NO: U-B/1 does not permit profiling. Contract UNKNOWN: S-F1/1 confirms the internal task only, not the new use. Retention YES: F1 processing and deletion facts are unchanged. Access NO: actual public recipients and further sharing contradict P-F1/1’s team-only restriction. Next step: data owner for purpose, rights administrator for rights, contract administrator for applicable contract evidence, security/access owner for the recipient and sharing restriction. No request grants public rights or changes HOLD.
What to do when evidence is missing
C: the internal instructions are I; purpose, rights U-C/1 and access P-F2/1 are documented, and F2’s scope covers I. Contract = UNKNOWN and retention = UNKNOWN, so C = HOLD. What is missing: evidence of a valid applicable contract, including addenda required by J-1, and evidence of retention periods and deletion for inputs, outputs, logs containing content and backups. Next step: the contract administrator and security verify those items, and the internal approver completes F2’s conditional authorisation. Missing evidence does not prove that the provider fails a requirement; it means the task does not yet have permission.
D: the public catalogue text is V, and all evidence applies to this exact case. D = ALLOW: O-D/1 and O-F1/1 establish class, purpose and audience; U-D/1 establishes rights; S-F1/1 the contract; R-F1/1 retention; and P-F1/1 access. Missing evidence: none. Next internal step: record the references and scope of the existing permission; J-1 requires no new approval for this defined task. If data, purpose, audience, environment or conditions change, first ask the data owner and security for a new assessment. ALLOW is a simulation result here, not an instruction to run anything.
Use only the fictional information in the worksheet. Complete four rows A–D by hand: class and reason, purpose/environment/audience, all six gates YES/NO/UNKNOWN with evidence, ALLOW/HOLD, reasoning, missing evidence and the next internal approval step. For each case, distinguish missing evidence from a known mismatch. Do not send anything to AI or open a real inbox, shared drive or team chat. Your result is a completed decision record, not a processed document.
Hint
Gate order: class, purpose, rights, contract, retention, access. A: D; NO/YES/YES/UNKNOWN/YES/YES => HOLD. B: V; YES/NO/NO/UNKNOWN/YES/NO => HOLD. C: I; YES/YES/YES/UNKNOWN/UNKNOWN/YES => HOLD. D: V; YES/YES/YES/YES/YES/YES => ALLOW. A needs an identifiability assessment, class authorisation and contract scope; B needs purpose authorisation, rights and contract scope; C needs contract and retention evidence; D needs a record of the valid scope, with reassessment only when it changes. Check that every row includes its next internal step. B also has access NO: actual public delivery contradicts P-F1/1. The security/access owner must assess the recipient and sharing restriction.
Reuse the four rows from the first exercise; annotate them rather than copying them again. Then answer four objections: A — “But we changed the name.” B — “The text is public.” C — “F1 has a contract, and the service supposedly does not train on our data.” D — “So now we can process anything?” Use only the fictional scenario and add no new evidence. Explain why each objection changes neither the original decision nor its scope.
Hint
Answer key: A = HOLD because D falls outside F1’s permission and its contract is UNKNOWN; D authorisation and contract evidence for D are missing, for the data owner, security and contract administrator to address. B = HOLD because purpose and rights are NO and contract is UNKNOWN; purpose authorisation, rights and applicable contract evidence are missing, for the data owner, rights administrator, security and contract administrator to address. C = HOLD because contract and retention are UNKNOWN; both items are missing, for the contract administrator, security and internal approver to address. D = ALLOW for the described summary only; nothing is missing, record the existing scope, and refer changes to the data owner and security. Renaming, public availability and vendor claims are not replacement evidence. B also has access NO: actual public delivery contradicts P-F1/1. The security/access owner must assess the recipient and sharing restriction.
Add proposed next steps to those same four rows. For A, propose which contextual features the data owner would need to assess when revising the record; do not claim that a revision automatically creates anonymity or permission. For B, propose a request to define a permitted purpose and usage rights. For C, draft a request for F2 contract and retention evidence. For D, record the limits of the documented permission. These are proposals within a fictional scenario only: send no messages, do not create evidence as if it were approved, and run no tool.
Hint
The original results remain A = HOLD, B = HOLD, C = HOLD, D = ALLOW. A: role, place and shift may identify someone; D authorisation and contract evidence for D are missing; next step: data owner + security + contract administrator. B: purpose authorisation, rights and applicable contract evidence are missing; next step: data owner + rights administrator + security + contract administrator. C: contract and retention evidence are missing; next step: contract administrator + security + internal approver. D: nothing is missing; record the scope, and refer changes to the data owner + security. A proposed revision or request does not change a decision by itself. A new result requires reassessing every gate and actual internal confirmation outside this simulation. B also has access NO: actual public delivery contradicts P-F1/1. The security/access owner must assess the recipient and sharing restriction.
- The organisation defines classes and permitted processes. V, I, D and P are only the fictional teaching policy J-1 here.
- Permission covers specific data, purpose, rights, environment and audience. Public availability, an enterprise label, disabled training or self-hosting does not establish approval on its own.
- Check all six gates: class, purpose, rights, contract, retention and access. Missing required evidence = UNKNOWN => HOLD; a known mismatch, NO, also means HOLD.
- Renaming is not evidence of anonymity. A’s context preserves identifiability and the restrictions of class D.
- Answer key: A = HOLD, B = HOLD, C = HOLD, D = ALLOW for the defined internal summary only. Record the reason, evidence gaps and next internal step for each.
- HOLD refers a question to the responsible role; ALLOW has an evidenced scope. The entire exercise is fictional: nothing is actually processed or uploaded.
Before moving to tool approval, check your four rows against the answer key: can you explain each HOLD and the narrow ALLOW, and identify the next internal step? This decision record helps you distinguish service features from your organisation’s permission. Choosing a tool does not replace the decision about data.
2/6 complete — keep going!