Data minimisation
Keep PMT data minimal
PMT is designed for selected operational results, not broad data collection.
Before sending a field, ask whether the operational question actually requires it.
Select deliberately → collect less → transmit less → store less → expose less.
The safer default
Send the result, not the surrounding data.
If the useful answer is free_disk_gb = 7.4, PMT does not also need user files, broad inventory, event logs and unrelated machine telemetry.
What not to send
Do not use PMT as a convenient transport for information the selected operational result does not require.
SECRETS & CREDENTIALS
Do not place passwords, API keys, access tokens, private keys or other reusable secrets inside station names, sensor/check names, tags or values.
PERSONAL / PAYMENT RECORDS
Avoid personal records, payment/card data and other unnecessary identifying information.
If the operational result can be expressed without identifying a person, prefer that form.
RAW OR BROAD DATA
Avoid large diagnostic logs, broad endpoint inventories, user activity, file contents and unrelated machine telemetry.
PMT is not a log-ingestion, document-storage or general telemetry platform.
Keep operational identifiers operational.
stn, sens and optional tag should identify the source/check/grouping needed for the task.
Prefer names such as:
SERVER-3 backup_result branch-a pump_temperature
Avoid embedding unnecessary personal details, secrets or narrative data in identifiers merely because the field accepts text.
Use optional data only where the use needs it.
tag is a short three-character field. ts_dt supplies source observation time. ttl can shorten retention but cannot extend the effective policy. Exact lat/lon is POST-only, permission-gated and withheld from normal customer egress.
If the operational question does not need an optional field, leave it out.
Descriptive names are normally simplest.
Most checks can use descriptive sens identities such as:
backup_result free_disk_gb sync_status
That keeps deployment understandable and removes unnecessary mapping.
Opaque identifiers can reduce visible meaning — but they are not encryption, and stn itself is source-supplied rather than a cryptographic identity.
Where there is a real benefit, a numeric/opaque identity can reduce how much human meaning is present in raw telemetry.
If the mapping is obtained elsewhere, the meaning may become obvious.
Semantic compartmentalisation is not a substitute for authentication, encryption, access control, token security or project separation.
PMT cannot make a careless payload safe by policy or by credential scope.
This page is operator guidance.
Do not assume PMT technically prevents every form of sensitive data from being placed into an accepted field.
The best minimisation decision is made at the source, before transmission.
PMT is designed around data minimisation and GDPR-by-design principles, but software alone cannot make every use automatically GDPR compliant.
Four useful kinds of minimisation
- Volume: collect selected results rather than broad telemetry.
- Semantic: avoid unnecessary human meaning where opacity genuinely helps.
- Access: expose only the projects/views required by the authorised viewer.
- Retention: retain operational results only for the intended purpose and policy.