Use data with a purpose.

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

Start with what the data is for

Our fictional project supports human review of school equipment requests. It does not automatically allocate equipment, profile students or target marketing. This purpose determines what information is justified and what evidence the system needs.

The data-card workbench asks you to choose fields and describe their source, permitted use and handling. It contains field descriptions, not real personal records. Keep your notes fictional. The downloadable card is a proposal for discussion, not verified permission or a security mechanism.

A field can help one task and create another risk

A random request ID helps join a request with its eventual outcome without putting a name in every analysis table. This is pseudonymization: a mapping or other information may still link the ID to a person. It is not necessarily anonymization, which would require much stronger evidence that people cannot be identified in the relevant context.

Request-time need and deadline information support the proposed prediction. The later reviewer outcome supplies the label used for training or evaluation. It must not be included as an input to a model predicting that outcome before review. This would leak future information. The collection channel may support an error audit even if it is excluded from prediction inputs.

Full names and home addresses have no stated role in this analysis table. A separate operational service may need contact details, but that does not justify copying them into model training. Private counselor notes are outside this stated purpose. The workbench lets you remove those fields and inspect what capabilities remain.

Minimization does not mean removing everything

Data minimization means retaining justified information for the purpose, with appropriate limits. Removing the outcome label prevents the supervised evaluation proposed here. Removing the collection channel prevents this channel-based audit. Removing a name can reduce direct identification while still leaving linkable information elsewhere.

The visible field count is only a count. Six low-risk fields are not necessarily more exposing than one highly sensitive field. The lab therefore explains specific concerns instead of inventing a privacy score or claiming that fewer columns automatically make a dataset safe.

Provenance, permission and access are different

Provenance records where information came from: who collected it, when, by what method, with what transformations and under which source terms. Permission concerns whether this proposed use is covered. Access concerns who can obtain the records. Having access does not establish permission, and a permission claim does not establish data quality or secure handling.

A publicly downloadable file still needs a source and purpose review. An agreement about event notifications does not automatically authorize training a marketing predictor. Consent, when relevant, has a scope and context; it is not a universal checkbox for every future use. Actual requirements depend on the setting and jurisdiction, which this fictional exercise does not determine.

In the lab, choosing “documented” merely records the learner’s claim. It cannot inspect an agreement or verify what people understood. Record the supporting evidence in a real review process before relying on that claim.

Retention is a plan that needs implementation

Retention is how long information is kept and why. A shorter justified period can limit exposure, but a deletion date needs an owner and a process that addresses copies, exports and backups. Thirty days is a teaching option, not a universally correct requirement. A year may be justified in some contexts; explain the need instead of assuming it.

The workbench does not enforce deletion or access control. Its JSON export contains your notes and proposed fields, not a running retention service. Local storage and pseudonyms are not substitutes for appropriate handling.

Make a reviewable data card

A useful card states the purpose and excluded uses; source and collection process; field roles and units; label definitions and limitations; permission evidence; intended access; retention and deletion process; and what the data cannot establish. Keep labels, prediction inputs and audit-only attributes distinct.

In the lab, remove unjustified fields, restore any needed labels or audit fields, and describe the remaining limitations. Then change the proposed use to automatic allocation or marketing and identify what must be reconsidered. A card can reveal unanswered questions; completing every field does not establish that a model is useful or a deployment is appropriate.

Use the data-audit project to connect this proposal to actual preprocessing and evaluation evidence. Its licensed Iris dataset provides a concrete source and transformation manifest; it is a different dataset from this fictional human-request scenario. Neither a completed card nor an automated checklist replaces independent review of implementation and decision quality.