Data Authorization Mechanism Statement

Version 1 · Trajector · PublicAI Foundation

Status of this document. This statement is an annex to Trajector's data purchase agreements, and it is public. §§1.3, 3, 4 and 5 are the representations Trajector makes to data purchasers; §§2 and 6 describe the mechanism and the limits of what it establishes. Changing how the mechanism works therefore requires a contract amendment — that constraint is deliberate: a guarantee we could change at will would not be a guarantee.

A machine-readable license field ships with standard-profile deliveries. It is a short stub, not a full expression of the terms, and it is not published in a standard vocabulary. Where it and this statement differ, this statement governs.

Trajector supplies development-session data contributed by individual developers. This document describes how contributor authorization is obtained, what each authorization record contains, what it is worth as evidence, and how a purchaser can verify it independently without receiving any contributor's identity.

It follows the Source / Provenance / Use grouping of the D&TA 22-field data provenance schedule, so that it maps directly onto a standard procurement diligence checklist.

1 · Source

1.1 Who the contributors are

Individual developers who install the Trajector client on their own machines and enable recording for specific projects. Every session in a delivery originates from a contributor account that holds an authorization record described in §3.

1.2 How an account is established

1. Sign-up — email address and password, or a Google / GitHub identity.
2. Email verification — a one-time link proves the address is deliverable and controlled by the account holder. Until it is used, the account cannot pair a device or request a payout.
3. Beta admission — accounts are admitted from a waiting list by a Trajector operator.
4. Data authorization — §2.
5. Device pairing — an account without a current authorization cannot obtain an upload credential. Independently of that, a session no authorization record covers is never delivered: coverage is materialized per batch on receipt (§3.3).

1.3 Identity verification — the boundary, stated plainly

Identity verification. Trajector verifies that the email address on each account is deliverable and controlled by the account holder. Where a Google or GitHub identity is linked, the provider and the provider-side subject identifier are recorded in the authorization record (§3.1). Trajector does not perform identity-document verification (KYC) and does not represent that the personal name supplied by a contributor is that person's legal name.

The binding party to each authorization is the account — identified by its verified email address and, where present, its linked third-party identity — not the supplied name. Each authorization record therefore attributes consent to an account Trajector has verified, at a timestamp Trajector recorded; it does not attribute consent to a natural person whose legal identity Trajector has confirmed.

This is stated first because it determines how much weight the rest of the document can carry. What Trajector can stand behind is the account identity chain; a supplied name is a self-declaration and is recorded as such.

2 · How authorization is obtained

2.1 The act

Authorization is given in the contributor's Trajector dashboard, after the email address is verified and the account is admitted. The full text of the authorization document is displayed on the page — not a summary, not a link. The contributor enters the name they wish to appear on their archive copy, is told in the same screen that Trajector does not verify names, and confirms.

Trajector records the moment it delivered that document text to that session, and the moment the contributor confirmed. It does not record any client-reported "I have read this" event: that would be a claim by the browser, and Trajector cannot stand behind it.

Electronic-signature consent is recorded as a separate consent, because in law it is one.

2.2 Document versioning and archival

Each authorization names a document and a version, and stores the SHA-256 of the exact bytes of that version. Those bytes are kept as a frozen copy that is never edited; the working copy used for editorial review is a different file. A purchaser who asks for the text behind a document_hash receives the frozen bytes, and can hash them.

2.3 What the contributor grants

See the authorization document itself (supplied with this annex). In summary, it is a perpetual, worldwide, irrevocable, sublicensable and transferable license to use, reproduce, modify, create derivative works from, distribute and publish the contributed sessions — the sublicensing right is what permits Trajector to supply the data to purchasers at all.

⚠ The license is bounded by purpose, and the purposes are named in the document itself (§1.1). There are three, and a use outside them requires a new version of the authorization, accepted afresh by each contributor:

1. Sale to data purchasers — the sessions themselves, or material compiled and combined from them, supplied to identified buyers under written contract. This includes use for training, evaluating and improving AI models, by Trajector or by the purchaser.
2. Research — the same material as sample or source material for research, including research published as academic papers, whether Trajector's own or a third party's.
3. Public release of a selected portion as an open dataset, under the licenses named below, typically accompanying published research.

A purchaser should read the boundary as a strengthening, not a restriction: the contributor was told these three and nothing else, so the authorization Trajector relies on is one the contributor could actually have expected. A grant written broadly enough to cover anything is a grant a contributor can later say they never understood.

⚠ What item 3 means for a purchaser. Some portion of the material may also be published openly. Trajector does not treat exclusivity as implied by a sale. Where a purchase agreement requires that specified material is not published, that is a term of that agreement and Trajector honours it by excluding that material from any publication; publication decisions are made per dataset, never automatically. Anything published is reviewed again first — for personal data and for third-party material that may not be redistributable — and carries no contributor identity.

⚠ Under what licenses an openly published dataset goes out. Two, because one does not cover the ground:

• Open Data Commons Attribution License v1.0 (ODC-By) over the dataset as a database — its selection, arrangement and structure;
• Creative Commons Attribution 4.0 International (CC BY 4.0) over the contents of that dataset — the session material itself.

ODC-By governs a database and, by its own §2.4, does not govern the contents of that database; naming it alone would leave the session material carrying no license. Attribution under both runs to the named dataset and to PublicAI Foundation (the Licensee), never to a contributor — consistent with the anonymity rule above.

These two are named in the authorization document itself, at §1.4 of v2.1 (the version accepted by contributors from 5 September 2026). Contributors who accepted v2, whose text said only that a published dataset "carries an open license to the public", are not asked to accept a new version; Trajector applies the same two licenses to material covered by v2, which is within what v2 authorized. Changing either license requires a new version of the authorization, accepted afresh.

For material covered by v2.1, what a competitor can obtain for free, and on what terms, is stated in a document whose exact bytes are hashed into every record that accepted it, so that any later alteration is detectable by anyone holding the hash. For material covered by v2 it is Trajector's stated choice within the license v2 grants, and this annex is what binds it.

3 · Provenance — the authorization record

3.1 What each record contains

The OAuth provider and subject are recorded because a provider-side subject identifier is stable while an email address is not. Where an account has linked more than one provider, the earliest linked identity is the one recorded. An empty pair means that no linked identity was recorded at acceptance; it does not establish that the account had none. The identity chain of such a record is the verified email address and its verification timestamp.

The full User-Agent string is retained rather than a coarsened form: in a dispute, "the same browser" is the only thing it is useful for, and coarsening it removes exactly that use. Trajector records no inferred values (for example, a country derived from the IP address): they establish nothing and can contradict the declared jurisdiction.

3.2 Immutability

Authorization records are append-only, enforced in the database: any UPDATE or DELETE raises an error. Nothing derived from a record is written back into it — the archive copy, its storage location, and its digest all live in separate append-only tables for exactly this reason.

3.3 Coverage — which sessions an authorization covers

An authorization covers every upload batch received by Trajector after the authorization was made. The unit is the batch, and the timestamp is Trajector's receipt time, not a client-reported upload time — the former is what Trajector can stand behind.

Because a single session is uploaded in fragments that may span several batches, Trajector applies a stricter rule at the delivery boundary: if any fragment of a session is not covered, or if fragments fall under two different authorizations, the entire session is excluded from delivery. No partial sessions are ever supplied.

Authorization is not retroactive. Data uploaded before a contributor authorized is not brought into scope by a later authorization.

3.4 One strength of evidence across the pool

Every delivered session is covered by a record that holds the full set of fields described in §3.1 and was made in the flow described in §2. A delivery may contain sessions covered by two document versions, v2.1 and v2, and each session states which one applies (consent.agreement_version). The two carry the same evidence strength. The records hold the same fields and are made the same way; only the document text differs, in the respects §2.3 and §7 describe. A session covered by v2 is not weaker than one covered by v2.1.

Sessions covered only by an agreement earlier than v2 are not delivered.

The version is stated on every session so that a purchaser can tell v2 from v2.1 where the difference in the document text matters.

4 · Use — what is delivered, and what is not

4.1 Contributor identity is not delivered

Deliveries contain no contributor identity: no name, no email, no account id. Each session instead carries a contributor_ref — an HMAC of the internal account id under a key unique to that delivery batch. A purchaser can therefore count contributors and compute authorization coverage for themselves, but cannot learn who anyone is, and cannot link the same contributor across two deliveries from these identifiers alone.

Where a contract requires an identified authorization, that is a separate, deliberate transmission — §5.2.

4.2 Personal data in the delivered sessions

Session content is redacted for secrets and credentials on the contributor's own machine before upload, and is scanned a second time on receipt. The second scan is a detector, not a masker: a session it hits is rejected in full and never delivered. It is not a warranty that a delivered session contains no personal data — see §6 item 5.

A contributor may request deletion of their contributed data; that deletion takes effect in Trajector's systems, in all future deliveries and in any future publication. It has no retroactive effect on copies already delivered to a third party — Trajector does not require a purchaser to delete copies already delivered, and the verification described in §5 continues to work for them.

⚠ Material that has been published as an open dataset (§2.3 item 3) is beyond the reach of a later deletion request altogether, and the authorization document says so to the contributor in those words. This is why anything selected for publication is reviewed a second time before it goes out, and why only a selected portion is ever published.

5 · How a purchaser verifies all of this

5.1 Per-delivery, without contacting Trajector

Every delivery ships an _attestation.json containing an authorization section: one entry per (contributor_ref, agreement_version) pair, each with an authorization_digest, plus a Merkle root over those entries (RFC 6962), and an ed25519 platform signature over the whole document. The format permits signature to be null, in which case the digests and the Merkle root ship unchanged; an attestation with a null signature did not come from Trajector's production system, and a purchaser who receives one should say so to Trajector.

The check is a set comparison:

The set of (contributor_ref, agreement_version) pairs appearing on the delivered sessions must equal the set of entries in the authorization section.

Recomputation rules are written in full in the delivery documentation, and can be executed with any SHA-256 implementation. A purchaser who does this establishes, without trusting Trajector's arithmetic, that every delivered session is backed by an authorization record that existed and was unmodified at the moment the attestation was produced.

5.2 On request, for a named contributor

Where a contract provides for it, or in a dispute, Trajector issues a Certificate of Authorization Record for a specified authorization. It contains the record's canonical pre-image, its digest, and the contributor_ref for the relevant deliveries, so that the purchaser can tie it back to the authorization root they already hold. The certificate is a signed JSON document; any PDF is a rendering of it.

Issuance is performed by a Trajector operator against a stated contractual or dispute basis; each issuance is recorded in an append-only log naming the recipient, the operator and the basis. There is no self-service interface for this, by design.

5.3 The contributor's own copy

Each contributor receives an archive copy of their authorization, carrying the same record digest that appears on a certificate issued to a purchaser, and a public verification address where anyone holding the digest can confirm the document, version, document hash and timestamp of the record. That page discloses no identity.

6 · What this does not establish

Stated here rather than left to be found:

1. It does not establish that a contributor's name is their legal name. Trajector performs no KYC (§1.3).
2. It does not establish that a contributor was entitled to license what they contributed. That is an undertaking the contributor gives in the authorization document; it is not a fact Trajector verified. It is a representation and warranty backed by an indemnity capped at the rewards that contributor received.
3. It does not establish that Trajector's authorization table contains no fabricated rows. A signed root shows only that these leaves existed when Trajector signed it.
4. The time anchor holds only from the moment a root was handed over. Records made before Trajector's first delivery could in principle have been altered before that point; the append-only enforcement is internal and not externally observable.
5. It does not establish that a delivered session contains no third-party personal data, and it does not establish that third-party code inside a session may be redistributed. Redaction on the contributor's machine targets secrets and credentials; the second scan on receipt targets the same, plus email addresses and telephone numbers, and it rejects rather than masks. A session still carries whatever its file paths, file contents and command output contain. The authorization covers what the contributor could grant (§2.3, and the contributor's own undertaking at item 2); it does not reach a third party's rights.

Item 4 is the real boundary of the evidence chain. It is stated because a purchaser finding it unaided is worse than Trajector stating it, and because stating it is what makes items 1 to 3 worth relying on. Item 5 lies on a different axis: it is about the content of the sessions, not about the authorization record.

7 · Governing entity

The licensee under each authorization is PublicAI Foundation, a foundation company incorporated in the Cayman Islands. Those authorizations are governed by Singapore law, with disputes referred to SIAC arbitration seated in Singapore before a sole arbitrator, subject to two carve-outs preserving contributors' rights where local mandatory consumer law applies and for small-claims proceedings. Under v2.1, the choice of Singapore law leaves intact any protection of the contributor's place of residence that cannot be departed from by agreement, and the SIAC and arbitrator's fees for an individual claim a contributor brings fall on the licensee; the licensee has undertaken the same fee treatment towards contributors who accepted v2 (v2.1 §11).

As a Cayman entity, PublicAI Foundation's processing of personal data is subject to the Cayman Islands Data Protection Act, 2017. Where personal data is collected, used or disclosed in Singapore, Singapore's Personal Data Protection Act 2012 applies to that processing as well.