Data sovereignty and zero-state telemetry

Zero-state telemetry is the design goal governing how the PointSav platform intends to measure usage of its public surfaces: no personally identifiable information retained, no tracking cookies, no session state — aggregate signal without individual records. Paired with it is the broader principle of data sovereignty: that operational records generated by a deployment belong to the customer, run on infrastructure they control, and are not exported to a vendor or a third-party measurement provider. Zero-state is a security posture as much as a privacy one — a telemetry store that never contained reader identity is a store whose breach discloses nothing about readers, which is the cheapest possible incident response available.

That goal is not met today, and this article's first job is to say so plainly. The platform's real ingestion pipeline currently records the requester's full, unmasked IP address alongside the timestamp, requested URI, and user-agent string for every request it logs, and retains the raw record for up to a year. The gap between the stated design and the running code was found by direct inspection of the ingestion source and has been escalated internally as a compliance-relevant discrepancy; it remains open as of this writing. What follows describes the intended architecture, the pipeline's actual behaviour — verified directly against canonical source — and the specific work required to close the distance between them.

What the pipeline does today

The measurement pipeline consists of two programs in app-mediakit-telemetry, both read directly from canonical source for this article.

The collector (telemetry-daemon) accepts a JSON body containing a requested URI, a timestamp, and a full user-agent string. It obtains the client address from the x-forwarded-for request header, taking the first comma-separated value, and falling back to a placeholder address when the header is absent. It then writes a single quoted comma-separated line containing the address, the timestamp, the URI, and the user-agent to an append-mode plaintext ledger file. The address is written verbatim: no masking, truncation, hashing, or generalisation of the client address occurs at any point in the collector.

The second program, omni-matrix-engine, reads that file, skips rows carrying the placeholder address, and performs a geographic lookup for every remaining address against a locally held MaxMind GeoLite2 City database, extracting country, first subdivision, city, and time zone. It buckets events into rolling windows and writes a summary report. It too operates on the raw address string, and it must: a masked address does not resolve to a useful city-level result, so the current design actively depends on holding the complete value at that step.

The collector's exposure

Two further properties of the collector are relevant to a security reading. The collector accepts submissions from any reachable caller with no authentication — its own source comment attributes this to accepting mesh traffic over the platform's WireGuard network — and its CORS configuration permits any origin.

Taken together, the endpoint accepts a record from any caller that can reach it, and the values it stores are supplied by the caller: the URI, timestamp, and user-agent are read from a submitted JSON body rather than observed by the server, and only the address is derived from a header. A record in the file therefore attests that something posted it, not that a page was actually viewed. Anyone building analysis on this data, or assessing its sensitivity, should treat it as caller-asserted rather than server-observed.

Public-facing descriptions of this platform's telemetry as a zero-state, masked, or privacy-preserving architecture describe the intended posture, not current behaviour. This gap has been escalated to platform governance rather than resolved in documentation, and remediation — masking before persistence, or restructuring the geographic step to work from an already- generalised value — has not been implemented as of this writing. It is a system change the team owning the telemetry component needs to make, not a wording change.

Retention and rotation

A deployment script rotates the live file into a date-stamped archive, restarts the collector, regenerates reports, then deletes archived raw files older than 365 days and generated reports older than 30 days.

Two things follow. First, raw rows containing complete client addresses persist for up to a year; this is a bounded retention policy, not a zero-retention one. Second, the rotation performs no anonymisation — it is time-based deletion only, so an address is either fully present or fully gone, with no intermediate generalised form retained for long-term analysis.

No timer or scheduled unit that invokes this rotation script was found in canonical source, so its actual execution cadence in a given deployment could not be established here. The file itself is not committed to the repository, and neither is the geographic database; both are runtime or operator-provisioned artefacts, so no size or row count can be reported.

What the sovereignty claim does hold

Several structural properties of the design are accurate as stated and are worth separating from the masking gap, because they are the substance of the data-sovereignty claim.

The measurement runs on the operator's own infrastructure. The collector, the analysis program, and the output file are components of the deployment itself. There is no call to an external analytics provider, no third-party script embedded in a served page for measurement, and no export of the record to a vendor-operated service.

Geographic resolution is offline. The lookup runs against a database file held locally on the same machine. No address is sent to a remote geolocation service for resolution. The operator provisions the database themselves under their own licence, and it is deliberately not redistributed inside the repository.

No cookies are set. A whole-tree search of canonical source found zero occurrences of a Set-Cookie header anywhere in the platform, and no consent-banner component of any kind. A published privacy page for one of the marketing surfaces states that the site sets no cookies, runs no third-party analytics, advertising, or tracking scripts, and shows no consent banner because there is nothing to consent to. The cookie-free claim is consistent with what the source shows — resolving what an earlier pass had left as an open flag.

That said, two qualifications belong alongside it. A separate marketplace surface does use a functional session token for signed-in licence status, which is a session mechanism rather than a tracking one but is not "no state at all." And a set of proposed public-site mockups held in the tree contain a far more detailed client-side beacon — referrer, viewport, time zone, device memory, processor count, scroll depth, dwell time, click targets, network type — posted to a telemetry endpoint with no consent prompt, alongside marketing copy on the same page claiming a "Zero-Cookie and Zero-State Telemetry architecture." Whether those mockups are deployed on any live surface could not be determined from source, and they are flagged here rather than assumed inactive.

What this is not

This is not a masked or anonymised telemetry pipeline. Complete client addresses are written to a plaintext file and retained for up to a year. Any statement that a final octet is dropped, or that addresses are hashed before persistence, is inaccurate as a description of running code.

This is not a description of a compliance position. The design intent is aligned with data-minimisation principles, but a pipeline that stores unmasked addresses alongside timestamps, requested paths, and full user-agent strings handles personal data, and this article should not be read as asserting that any particular regulatory obligation — GDPR, PIPEDA, or otherwise — is satisfied. That assessment is a matter for the operator and their advisers.

The absence of cookies is not the absence of identifiers. An address paired with a user-agent string and a request path is a re-identifiable record in many contexts. Cookie-free measurement reduces cross-site linkage; it does not make a record anonymous.

Time-based deletion is not anonymisation. Retention limits exposure duration. Within the retention window the record is fully identifying.

Zero-state is not the current state. It is the target the design is written toward. Whether the pipeline's present behaviour is consistent with any specific data-protection regime is a legal determination outside this article's scope; what this article asserts from direct source inspection is narrower and verifiable: full IP addresses are being written to persistent storage today, and the zero-state architecture is a target, not a description. Nor is this an incident report — there is no finding here of unauthorized access or misuse of the logged data, only of a divergence between design and implementation — and no timeline is attached to the remediation above, because none has been committed.

See also

• Zero-state telemetry architecture — the wider architectural position on operator-held measurement
• Telemetry architecture — the structure of the collection and analysis pipeline
• app-mediakit-marketing — agent-authored marketing landing server — the served surface whose published privacy page is quoted above
• Cryptographic ledgers — the append-only record used for auditable events, distinct from this pipeline
• Customer-owned graph IP — the ownership principle applied to derived data
• Machine-based authorization