Sensitivity, purpose and permissions

A model can describe who participates, why information is used and what a permission covers. Those distinctions matter—but describing them does not authenticate anyone or grant access.

“The seller may see the report” leaves too much unstated

Which seller, in which transaction? Which report and version? Does “see” mean read an extract, download the entire document, amend it or share it further? For what purpose and period? Who supplied the permission statement, and what standing does it have?

These are modelling questions before they are implementation questions. A useful account must distinguish the participant's domain role from a description of permission. Someone being a seller does not establish entitlement to every record connected to the dwelling, just as the word “borrower” does not identify every arrangement in which someone participates.

Read the three claims separately: “Nia participates as seller in transaction T”; “a specified permission description concerns Nia, a named report, action, purpose and period”; and “an implementing service evaluates and enforces its applicable policy”. The first does not imply the second, and recording the second does not perform the third.

Classify the information you actually mean

A property report may combine descriptions of a building with information relating to identifiable people, contact details or restricted source material. It should not inherit one undifferentiated label merely because its main topic is “property”. The relevant classification may concern an individual statement, an attachment, an extract or the document as a whole.

Personal-data and sensitivity classifications answer different questions from document status or topic. “Issued” is not the same as “public”. “About a dwelling” is not evidence that a record contains no personal information. A classification should say what it covers, who assigned it, under which defined scheme and at which relevant time.

The model must be able to preserve distinctions that the agreed handling requirements need. It does not follow that every private fact should be copied into modelling evidence. A restriction-aware description can explain why a source matters without disclosing its protected content; Bring evidence others can interpret shows that review practice.

Participation and purpose are not permission

A transaction role describes participation in property work: seller in T, borrower in A or guarantor in B. A scheme role describes a separately defined capacity within a data-sharing scheme. A permission describes allowed actions with a scope and conditions. A person or organisation may be connected to all three, but none should be inferred merely from the others.

Purpose explains why a particular use is intended. Reading an inspection extract to review an access description is not the same purpose as using its contact details for unrelated marketing. A purpose statement helps identify that difference; merely writing down a purpose does not establish that the use is allowed.

Consent, a legal basis for processing and permission are also not synonyms. A record may describe a person's expressed consent; a legal-basis statement concerns the justification under applicable rules; a permission can concern a specific action on a specific resource. Their validity and relationships need appropriate evidence and authority. This chapter does not decide what legal basis applies to any real case.

A proposal we can actually review

The next specimen is an invented, unapproved permission description for a modelling exercise. It is not a real grant, scheme policy or statement of legal sufficiency. The source note expressly covers only the described action; no extension by role is allowed in these teaching premises.

Even with those limits, P is more reviewable than “the seller may see the report”. We can inspect the participant, information, action, purpose and period. We can also point precisely to what is not established. A detailed description can still be unauthorised; completeness of its fields is not approval.

The model's job is to preserve these distinctions

A downstream implementation may authenticate an actor, evaluate applicable policy, allow or refuse an action and record what happened. Those are operational responsibilities. A diagram or model annotation does not carry them out, prove valid consent or make OPDA the operator of a data service.

That boundary does not make the semantics optional. If an agreed specification says a permission description has a purpose and resource scope, dropping those qualifications in an exchange would lose part of the agreement. Practitioners can challenge that loss without designing an enforcement engine.

Scheme-level concepts should be reused or connected through their documented semantic home, not redefined independently in every property context. The broader Smart Data standard-versus-operator explanation remains the home for programme and Trust-framework context. Model-review decisions and that wider Trust Framework are different concerns.

A useful review contribution is: “This statement establishes a participant's role, but the proposed access claim needs its own resource, action, purpose, period and authority evidence.” No sensitive source material needs to be disclosed merely to demonstrate that missing distinction.