Skip to main content

Privacy Policy

Terms

Privacy Policy

Version 4.0, Effective 2 June 2026

Alter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049)

Who we are

Alter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049) ("ALTER", "we", "us", "our") operates identity infrastructure: the neutral rails that let a person be verified and recognised, on their own terms, across services. ALTER attests and verifies identity. It does not incorporate you, act as your agent, transact, negotiate, or speak on your behalf; it is a record you own and control, read by whoever you allow. "Discovery" is how a person grounds their own identity record from what they have manifested rather than what they declare: pairing the external streams they choose to connect, and answering a short member-only set of questions. It is not a psychometric test, a quiz, or a clinical assessment, and at this release no language model extracts traits from it. "Identity Income" is the earnings stream a person accrues when their identity data is queried. Downstream uses, including alignment between two members who have each consented, are consuming queries that run against the identity layer under your consent; the identity layer is the service.
  • Legal entityAlter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049)
  • Registered officeQueensland, Australia. Full postal address available on written request to privacy@truealter.com
  • Websitetruealter.com
  • Privacy contactprivacy@truealter.com
  • Data controller (GDPR)Alter Meridian Pty Ltd T/A True Alter
  • Applicable lawAustralian Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs); the UK Data Protection Act 2018 and UK GDPR; the EU General Data Protection Regulation (Regulation (EU) 2016/679); the EU AI Act (Regulation (EU) 2024/1689); the California Consumer Privacy Act as amended by the California Privacy Rights Act (CCPA/CPRA); and other jurisdictional laws where ALTER is offered
The Privacy Act 1988 (Cth) gives effect, in part, to Article 17 of the International Covenant on Civil and Political Rights: the right to be free from arbitrary or unlawful interference with privacy. We take that as the floor of what we owe you, not the ceiling. Where the common-law baseline has historically stopped short of recognising a proprietary or fiduciary right in a person over their own records, we commit at the protocol level to the stronger position: you are the subject and the source of your identity data, and our defaults reflect that.

How the service is reached at launch

At the present release the live surface is the MCP identity protocol. We describe the surfaces that reach live data and trigger the processing described in this policy, so the basis of each commitment below is concrete.
  • The MCP identity protocolThe primary live surface is an MCP (Model Context Protocol) server reached by AI agents over JSON-RPC at mcp.truealter.com. At this release agents can verify whether a human is registered, read a profile, attest or dispute a domain attestation, create an unclaimed identity stub for a person not yet registered, run a consent-gated peer alignment query, and settle paid queries over the x402 micropayment protocol. Free identity-check tools require no payment; the peer alignment query is priced per call and runs only after the subject has granted the querying party by name. Psychometric assessment, language-model trait extraction, trait vectors, identity matching and belonging computation are not part of this release: those tools are gated out of the public protocol and the public agent manifest is stripped to match.
  • The alter command-line clientA person interacts with their own identity record through the alter binary, distributed via npm: account and session control; authentication factors, including passkeys; connecting, reviewing and disconnecting external streams under explicit per-stream consent; granting and revoking peers who may run alignment queries; reading accrued Identity Income; and managing alter-to-alter messages.
  • Public web pagesInformational surfaces at truealter.com, including this policy, the Terms of Service, the Cookie Policy overlay, and the origin and developer pages. The informational pages do not require an account and collect no identity input. The Discovery question seed runs inside the command-line client for signed-in members, under explicit consent shown before any answer is recorded; it is not a public web form at this release.
  • AuthenticationSign-in uses an OAuth loopback flow initiated by alter login, which redirects to the ALTER API sign-in surface. Pre general-availability, the web sign-in surface is restricted to operational principals; for end-users, sign-in begins with the command-line client.
  • Surfaces not open at this releaseSelf-serve web-based consent management, web earnings onboarding and withdrawal, and the organisational and workforce agent tiers are not open at this release. Where this policy commits to a right or control, we describe the channel currently available (the command-line client or privacy@truealter.com) and update this section when additional surfaces open.
Every commitment in the sections below binds regardless of which surface was used to reach the service.

What identity data we process, and how it was derived

We classify every piece of identity data by how it was derived. Consent, retention and access rules for each attribute depend on how the attribute was derived as well as what it is. We record, for each derived attribute, what produced it and under which consent, and enforce consent rules against that record. Identity is inferred from what you have manifested, not from what you declare about yourself.
  • Active, declarativeData given to us directly: name, email, passkey credentials, authentication factors, the ~handle you reserve, and basic profile attributes. This is the smallest part of the record.
  • Discovery question seed (under explicit consent)Answers to the short member-only Discovery questions, where you choose to complete them, used to ground your own identity record. Discovery at this release is a deterministic question seed, not a psychometric test and not a language-model extraction: your answers map to recorded signals through fixed, published logic, with no automated model reading your responses. The consent that authorised it and the inputs it drew on are recorded with it. Where a recorded signal would amount to special-category data, your explicit consent under Art 9(2)(a) is the basis.
  • Connected-stream data (under stream-specific consent)Where you explicitly connect an external account to your identity record, we receive data from that stream under a separate, documented, revocable consent granted under Art 6(1)(a). Each stream is its own consent: connecting one stream is not consent to infer anything else, from any other source, about you, and you can disconnect a stream at any time from the command-line client. The streams fall into four shapes: credentialed-self streams (where a third-party account attests to something about you), manifestation-surface streams (where identity is read from how you show up rather than what you claim), URL-based connectors (where you name a website you operate), and local-vault connectors (where a source on your own device is paired without its content leaving that device). Each connector displays its connection shape and what it contributes to your identity record before you connect it.
  • Peer alignment outputsAlignment tier labels and complementarity bands between two members who have each consented, computed from the inputs above. An alignment output is produced only after payment and a consent check, and only after the subject has granted the querying party by name. Numeric scores are never exposed to a querying party: only qualitative tier labels and bands leave the system. Trait vectors, identity matching and belonging computation are gated out of this release and are not produced or exposed.
  • Passive, aggregate (population observation)Behavioural patterns across the user base used to study how the identity protocol performs. Released to our learning pipeline only when a cohort of many distinct subjects contributes, so no row can be attributed to a single person. No individual aggregate observation reaches a third party.
  • Passive, individual (local only)Signals that would describe you as an individual, from passive observation, are processed by local software on your device and never leave it. They do not traverse our servers, are not available to any recipient, and are not available to any other user, any organisation, or to ALTER itself. Passive individual processing is device-only, and we do not override that.
  • Automatic (operational)Timing and sequence metadata for authentication, connection and rate-limit decisions, used for bot and replay detection; browser and OS metadata strictly necessary for service delivery; and IP addresses, irreversibly pseudonymised before storage.

Special category notice

Some identity signals are special-category data under GDPR Art 9, sensitive personal information under the Australian Privacy Act s 6(1), and sensitive personal information under the CCPA. Wherever a signal would draw on special-category data (from a connected stream or the Discovery question seed), only your explicit consent under Art 9(2)(a) can authorise it. At this release no psychometric test is run and no language model extracts traits about you. We do not derive emotion or affect, and in workplace and education contexts no affect inference is performed at all (see section 5).

Lawful basis for processing

We operate across several jurisdictional regimes simultaneously. The list below maps each processing activity to its lawful basis under the primary regimes.
  • GDPR Art 6(1)(a), consentEach external stream you connect, each context submission, and each peer you authorise to run an alignment query is a separate, documented, revocable consent. Each is its own basis; consent to one is not consent to any other form of inference. Research use of pseudonymised data and marketing communications are each their own, independent, revocable consent.
  • GDPR Art 9(2)(a), explicit consent for special-category dataWhere an identity signal would draw on special-category data (from a connected stream or the Discovery question seed), our basis is your explicit consent under Art 9(2)(a). The consent is collected before any such signal is recorded, recorded against the resulting attribute, and revocable. No psychometric assessment or language-model trait extraction runs at this release.
  • GDPR Art 6(1)(b), contractAccount creation, authentication, session management, and delivery of the identity service you have signed up for.
  • GDPR Art 6(1)(c), legal obligationAudit logging, financial-record retention, lawful disclosure requests, anti-discrimination compliance.
  • GDPR Art 6(1)(f), legitimate interestFraud prevention, abuse mitigation, integrity checks and bias auditing. We have run balancing tests; you may object under Art 21.
  • Australian Privacy PrinciplesAPP 3.3 applies to the collection of sensitive information: we only collect it with your consent, and only where it is reasonably necessary for, or directly related to, a function of the service. APP 6 limits secondary use. APP 8 governs cross-border disclosure; see section 9.
  • CCPA / CPRAWe treat any special-category identity signal as "sensitive personal information" under Cal. Civ. Code s 1798.140(ae). We do not use SPI for advertising; we do not "sell" or "share" personal data (as the statute defines those terms); we honour Right to Limit Use of SPI requests. See section 15.
  • UK GDPRSame bases as GDPR above, read with Part 2 of the Data Protection Act 2018.
Where processing depends on consent, you can withdraw it at any time by writing to privacy@truealter.com, without giving a reason, as easily as it was granted. Withdrawal is future-dated: it stops further processing from the moment we receive it, and does not itself affect processing already carried out on the prior basis or erase derivations already produced under that consent. To erase data already inferred under a prior consent, make a separate erasure request to privacy@truealter.com and we will action it under Art 17 GDPR. The Australian Privacy Act has no equivalent erasure right, so for Australian members we honour the same request as a binding service commitment; separately, APP 11.2 requires us to destroy or de-identify personal information once it is no longer needed for any permitted purpose. Where we rely on legitimate interest, you have a right to object; where we rely on contract, withdrawal may terminate the service it supports. We treat cosmetic consent as no consent at all: consent procured under structural disadvantage is not a basis we will rely on, so we apply the same standard as a design rule: plain language, granular grants, symmetrical withdrawal, and no dark patterns.

EU AI Act Article 5(1)(d), prohibited inference in workplace and education

Article 5(1)(d) of the EU AI Act forbids the placing on the market, the putting into service, or the use of AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except for medical or safety reasons. We honour this prohibition categorically. It cannot be lifted by user consent, by organisational consent, or by any contract.
  • No emotion or affect inference is performed, stored or exposed in workplace or education contextsWhen an alignment query is run in a collaboration-fit or co-founder context, the emotional-granularity dimension is dropped from both sides before any comparison is computed. Affect signals that might otherwise be derived from response timing, text, or voice are categorically not computed in those contexts, at any release.
  • The prohibition runs ahead of the jurisdictional surfaceWe apply it globally, not only to EU users, because the AI Act is the strictest rule we are subject to and because the prohibition addresses a categorical harm (structural power asymmetry against the subject) that does not change with geography.
  • Medical and safety uses are not offered through the ALTER serviceWe do not claim the Art 5(1)(d) medical and safety carve-out. If that ever changes, we will publish the basis, the safeguards, the notified-body conformity assessment, and the user-facing controls before the feature ships.
The gate is structural, not a policy promise: the emotional-granularity dimension is removed in code on the workforce-vertical path, so it cannot be lifted by user consent, organisational consent, or contract.

Return binding on every query we settle

Every query against your identity record must return value to you. This is a contractual return-to-extraction commitment: a paid query that draws on your identity data produces a return event recorded to your earnings ledger. The binding is part of the protocol, not the branding.
  • Identity IncomeWhen an agent pays to query your identity record, a contractually-fixed subject share routes to you via an append-only earnings ledger recorded against your identity record. The per-query share is described in the footer below. Accrued balance is tracked against your identity record from the first query; web earnings onboarding and withdrawal open in a subsequent release, and accrued balance carries forward to it.
  • Consent before extractionA paid alignment query is checked against your consent configuration before it returns anything. A peer can only run an alignment query against you after you have granted that peer by name; you can revoke the grant at any time.
  • Local-only processing (passive-individual)Where a connector runs on your device, the raw content stays on your machine. You read it; we do not; any recipient does not; and no other user or agent can.
  • Provenance recordA per-attribute record of what produced it, what consented to it, and what return events it triggered. We surface anomalies to you, not to any third party. You can read who has queried your identity record, and what you earned, from the alter command-line client.
  • Human reviewAny automated output (an attribute value, a descriptor, a peer alignment indication, or an integrity flag) can be sent for human review on request to privacy@truealter.com, with a documented outcome.

Identity Income share

75 per cent of every payment for a query against your identity record routes to you, the subject. The 75 per cent subject share is enforced in code. The remainder is allocated to the operation of the ALTER network, a shared cooperative entry point, and the ALTER Commons pool, published in the Commons Ledger and kept under review. The binding is testable: if you ever stop receiving a return event for a query that draws on your identity data, that is a defect and we want to hear about it at privacy@truealter.com.

Your self-serve rights

The primary written channel for every right listed below at the present launch is privacy@truealter.com; certain operations are also available via the alter command-line client, and self-serve web surfaces open in a subsequent release. Where a statutory right exists (Art 15 through 22 GDPR, APP 12 and 13, CCPA) we honour it under that statute; where the protocol goes further than statute requires, we honour the protocol commitment.
  • Access your identity dataA machine-readable export of the data we hold about you, including derived attributes and their provenance records, is available by request to privacy@truealter.com (JSON and CSV formats). A live summary of what the identity record currently says about you is available via the alter command-line client.
  • Correct your identity dataProfile fields can be corrected by request to privacy@truealter.com. Derived fields cannot be rewritten arbitrarily, but you can request correction, flagging, or re-derivation (where a derivation surface is live) through the same channel (Art 16 GDPR; APP 13).
  • Request human reviewAny automated output (an attribute value, a descriptor, a peer alignment indication) can be sent for human review by request to privacy@truealter.com. Review outcomes may confirm, adjust, or re-run the underlying decision, with a written record retained for seven years.
  • Withdraw consentConnection and grant withdrawal are self-serve from the command-line client (for example "alter unpair" for a connected stream, and "alter consent revoke", "alter alignment revoke", or "alter msg revoke" for grants), granularly, one stream or processing purpose at a time. For any consent that does not yet have a self-serve surface, the authoritative channel is privacy@truealter.com. Withdrawal is future-dated and stops further processing from the moment we receive it; to also erase data already derived under a prior consent, pair the withdrawal with an erasure request (see the row below). Symmetry is a design rule here, not a courtesy.
  • Delete your accountRun "alter forget" from the command-line client to start a 30-day grace window; run "alter forget --cancel" within that window to cancel. After the grace period, personal data is permanently erased across our storage, derived attributes are cleared, audit records are pseudonymised, and recipients are notified. If you have lost access to your account and cannot run the command, you can make the same request to privacy@truealter.com.
  • Object to processing based on legitimate interestWrite to privacy@truealter.com. We respond within the statutory windows that apply to your jurisdiction.
  • Restrict processing during a disputeContact privacy@truealter.com. We will pause processing to the extent required by Art 18 GDPR while the dispute is resolved.
We verify requester identity before acting. We do not charge for rights requests except where Art 12(5) GDPR and APP 12.8 expressly permit a reasonable fee for manifestly unfounded or excessive requests. As additional self-serve surfaces open, we will update this section and notify you of the new channels.

Automated decision-making and the right to human review

GDPR Art 22 gives you the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects you. We have designed the service so that no such decision is solely automated.
  • Automated inference from connected streams and the Discovery seedWhen you connect an external stream or answer the Discovery questions, the Service derives identity signals on that basis under your consent. At this release no language model extracts traits about you: stream-derived signals and Discovery answers map to recorded attributes through fixed, published logic. You can request a written explanation of what an input produced and why, and request that the output be re-computed, corrected, or flagged. The Discovery seed carries its own notice and explicit consent before any answer is recorded.
  • Peer alignment outputs are indications, not gatesNo querying party may treat an ALTER alignment tier as the sole basis for a decision that materially affects you. We publish this as a contractual requirement on every consuming query, and only qualitative tiers leave the system, never raw scores.
  • Integrity signals never translate to silent exclusionAnomalies in connection or session flow influence confidence, not access. You are never silently excluded on the basis of an integrity signal.
  • Meaningful information about the logicUnder Art 13(2)(f) and Art 15(1)(h), you can request an explanation of the logic, the significance, and the envisaged consequences of automated processing that affects you. We will respond in plain language, not a model card.
Express your point of view and contest the decision: both rights are built into the human review channel itself. You may also escalate, as described in section 15.

Cross-border transfers

Primary storage is in Sydney, Australia. Our production databases and our cache are all in Australian regions. A small number of named recipients operate outside Australia; the transfer mechanisms below apply.
  • EU and EEA to AustraliaStandard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, Modules 1 through 4 as applicable) are in place with every recipient. A Transfer Impact Assessment has been conducted against the factors set out in Schrems II (CJEU Case C-311/18) and is refreshed annually or on material change. Supplementary technical measures are applied, including personal-identifier filtering, pseudonymisation, encryption in transit and at rest, and strict purpose binding.
  • United Kingdom to AustraliaThe UK International Data Transfer Agreement (IDTA) or the UK Addendum to the Commission SCCs is in place. An ICO transfer-risk assessment is conducted to the standard set out in the ICO International Transfer Guidance.
  • Australia to elsewhere (APP 8)We remain accountable under APP 8.1 for any act done by an overseas recipient that would breach the APPs if done by us in Australia. Exceptions under APP 8.2 are narrowly applied and documented.
  • California data onward disclosureRecipient contracts bind each recipient to CCPA and CPRA service-provider restrictions: no use for their own purposes, no combination with other data, no onward sale or sharing.
A copy of the SCCs, the IDTA, and the Transfer Impact Assessment summary is available on written request to privacy@truealter.com, subject to redaction of commercially confidential terms.

Recipients and external streams

Under GDPR Art 13(1)(e), we name the recipients of personal data. The list below is current at the date of this policy; the live list is maintained on request and materially updated recipients are notified in accordance with our Data Processing Agreement with organisational customers.
  • Fly.io (United States parent, Australian region deployment)Application hosting and database compute, Sydney region. Personal data at rest in Australia; no Fly.io access to plaintext application data beyond what is necessary to run the service.
  • Cloudflare (global edge)TLS termination, denial-of-service protection, bot mitigation. Edge request logs retain IP addresses at the edge for a rolling window; we do not persist Cloudflare logs to our own storage and we do not use Cloudflare for analytics or tracking.
  • Coinbase (United States), x402 facilitatorSettles x402 micropayments for paid identity queries on the Base network. Receives the on-chain payment proof and settlement metadata, not your identity attributes. No card data is involved; payment is USDC on-chain.
  • SendGrid (United States, operated by Twilio Inc.)Transactional email delivery. Receives the recipient address and the message body.
  • Self-hosted error monitoring (Sydney region)Application error reporting. Personal-identifier filtering runs before submission; operated on our own infrastructure.
  • External streams (Art 13(1)(e) recipients, not ALTER recipients in the processor sense)Where you pair a third-party stream to your identity record, the provider of that stream is an independent data controller with whom you hold your own account. When you pair, ALTER receives data from that counterparty under your explicit Art 6(1)(a) consent. The counterparties fall into the shapes described at section 3: credentialed-self providers (third-party accounts that attest something about you), manifestation-surface providers (third-party services whose public output reflects how you show up), and URL-based sources you name yourself. A current list of the specific providers available at this release is published separately and kept current as connectors are added or removed. A local-vault connector does not send content off your device and therefore has no external recipient.
We do not use Google products, Google Analytics, or any Google-operated recipient in the service. Advertising networks are never recipients. Any change to this list that materially affects the protection of personal data is communicated by email at least 14 days before it takes effect.

Connector pairings: what pairing authorises and refuses

When you pair an external stream (GitHub, Discord, ORCID, a domain you control, an EVM or Solana wallet, and others as they ship), you are granting ALTER a read-only recognition right. Pairing is not delegation, account-linking, or sign-in. The grants below are exhaustive; anything not listed is refused at the connector boundary regardless of what the upstream provider would permit.
  • What pairing authorisesA scoped read of the public-or-OAuth-permitted fields enumerated on the per-connector page at /docs/identity/connectors/<provider>, refreshed at a defined cadence, used solely to derive contributions to your identity record under your Art 6(1)(a) consent.
  • What pairing does not authorise (OAuth-class connectors)ALTER cannot post, message, push, comment, merge, modify settings, change membership, or perform any write action on the upstream account. The OAuth scope we request is the smallest read-only grant the provider supports for the recognition pattern; tokens are held in a single rotating slot scoped to the connector and never reused.
  • What pairing does not authorise (attestation-class connectors)For DNS, .well-known, and wallet-attestation pairings, the proof is a public artefact you create (a TXT record you publish, a file you sign with your own key). ALTER never holds write credentials, signing material, or registrar control; the wallet attestation is a one-shot identity signature, not a session key.
  • Post-pairing safetyA successful pairing does not enrol you in any downstream surface. Peer alignment queries, paid agent queries, and organisational visibility each require a separate consent scoped to that purpose; the organisational and workforce tiers are not open at this release. Sharing is never transitive: granting recognition to ALTER does not propagate to anyone else, and a peer can only run an alignment query against you after you grant that peer by name.
  • RevocationEvery pairing carries a CLI revoke command and an in-product control. Revocation is immediate; it revokes the upstream OAuth grant where the provider supports revocation, destroys the access and refresh tokens on our side within 24 hours, removes the derived per-stream contribution at the end of the 30-day account-deletion grace period (or immediately on stream-level deletion request), and writes a tamper-evident audit row that you can inspect.
  • Per-connector disclosuresEach connector has its own page documenting exactly what we read, what we refuse, what we cannot do, where the evidence lives, and how to revoke. The index is at /docs/identity/pairing.
Where this section appears to differ from a connector page, the connector page governs for that connector. Where a downstream query (peer alignment, paid agent read) appears to authorise more than pairing does, the more restrictive scope governs and the additional consent must be obtained before any expansion takes effect.

Security

Security is measured as the worst reasonable case, not the average case. The measures below are maintained as technical controls, not policy aspirations.
  • Password hashingA memory-hard password-hashing function (Argon2id), appropriate for account protection. Passkeys (WebAuthn) are available and are the recommended factor for account binding.
  • Transport securityTransport-layer security (HTTPS) with strict-transport policies applied and preloaded. Internal service-to-service connections are encrypted in transit.
  • At-rest encryptionSensitive fields are encrypted at the application layer using authenticated encryption (AES-256-GCM), with key derivation from a managed root; database volumes are additionally encrypted at the infrastructure layer.
  • Store separationData of different kinds is held in separately credentialed stores with independent backup and access policies. Cross-store joins are disallowed at the application layer.
  • IP address pseudonymisationIrreversibly pseudonymised before storage. The raw IP address is not written to our databases. A Cloudflare edge log may hold the raw IP for a short rolling window at the edge only.
  • Personal-identifier filteringPersonal identifiers are filtered from content before it is routed to any external recipient. Unstructured free text you volunteer may still contain personal information that filtering cannot guarantee to remove; where we retain raw content, we apply short retention windows and narrow access.
  • Audit log hash chainThe audit log is a tamper-evident hash chain; any modification of a prior record invalidates every subsequent record and is detected on read.
  • Rate limits and abuse controlsApplied at the query, session and pairing layers to deter scraping and automated harvesting.

Breach response

Under the Australian Notifiable Data Breaches scheme (Privacy Act Part IIIC) and GDPR Articles 33 and 34, we notify the relevant supervisory authority within 72 hours of becoming aware of a qualifying breach, and affected individuals without undue delay. Given the sensitivity of identity data, we apply a low threshold for "serious harm" (Privacy Act s 26WE) and for "high risk" (GDPR Art 34(1)). We hold draft holding statements for the incident classes we consider foreseeable so that notification is fast when it matters.

Retention

Retention is set by purpose. We keep nothing longer than we can justify against the purpose, and we destroy on schedule, not by request.
  • Connected-stream tokensOAuth access and refresh tokens are retained while the stream is connected. When you disconnect a stream, the tokens are revoked with the provider (where the provider supports revocation) and destroyed on our side within 24 hours.
  • Discovery question-seed answersYour Discovery answers are mapped to recorded signals through fixed published logic and the raw answer is hashed for lineage, not retained. Where short-lived caching is needed for reliability, caches expire on a short rolling window.
  • Derived attributes and peer alignment outputsDerived attributes from connected streams and the Discovery seed are retained while your account is active and destroyed at the end of the 30-day account-deletion grace period. Numeric scores are held internally only; never released to a querying party.
  • Unclaimed identity stubsAn identity stub created by an agent for a person who has not yet signed up enters a 30-day pending state and is automatically deleted if unclaimed within that window.
  • Identity Income ledger entriesEarnings ledger rows are retained while your account is active, and the financial record is kept as long as legal record-keeping obligations require, pseudonymised at account deletion.
  • Consent recordsRetained for seven years under the audit hash chain. Required to demonstrate the lawful basis on which any processing occurred (Art 7(1) GDPR), and kept as a reasonable step under our APP 1.2 governance obligation.
  • Audit and compliance recordsSeven years. Hash-chained; pseudonymised at account deletion so that the record persists but the subject does not.
  • Anonymous or guest sessionsDeleted automatically after 30 days.
  • BackupsRolling retention aligned with the hosting provider default. Deleted records age out of backups within that rolling window and cannot be selectively restored.
  • Deletion grace period30 days from the deletion request, during which you can cancel by running "alter forget --cancel" from the command-line client, or, if you have lost access, by written request to privacy@truealter.com.
We log every destruction event in the audit chain so that a retention schedule can be proven as well as stated.

Children

ALTER is for adults aged 18 and over. We do not knowingly collect personal information from any person under 18. The service is not designed to meet the heightened requirements of child privacy regimes.
  • GDPR Art 8 (information society services offered to a child)Not applicable; we do not offer the service to children. If we become aware that a person under 16 (or the lower age set by an EU Member State, down to 13) has registered, we close the account and delete the associated personal data.
  • COPPA (United States, under-13)We do not direct the service at children under 13, we do not knowingly collect from them, and if we become aware of such collection we delete immediately.
  • Age-gateRegistration carries an explicit age confirmation. Misrepresentation of age is grounds for account termination; discovered misrepresentation triggers immediate deletion of associated data.
If you believe a person under 18 has registered or submitted data, email privacy@truealter.com and we will act on the same business day.

Complaints and supervisory authorities

If something has gone wrong, tell us first: privacy@truealter.com with the subject line "Privacy Complaint". We investigate, write back in plain language, and fix what we can. If our response is unsatisfactory, you have recourse to the regulator that covers you.
  • AustraliaOffice of the Australian Information Commissioner (OAIC): oaic.gov.au, 1300 363 992.
  • United KingdomInformation Commissioner's Office (ICO): ico.org.uk, 0303 123 1113.
  • European UnionYour local data protection supervisory authority. The European Data Protection Board maintains a directory at edpb.europa.eu. For the French example (CNIL): cnil.fr.
  • CanadaOffice of the Privacy Commissioner, and the Consumer Privacy Protection Act regime once in force: priv.gc.ca.
  • California, United StatesCalifornia Privacy Protection Agency: cppa.ca.gov. California Attorney General: oag.ca.gov/privacy.
  • Other US statesAttorneys General in states with comprehensive privacy statutes (Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and others as they come into force).

EU Article 27 representative

ALTER does not currently maintain an establishment in the EU and does not offer the service by targeting data subjects in the EU within the meaning of Art 3(2). We therefore consider ourselves not to be within the Art 27 designation obligation. If our offering to EU subjects changes, or if the competent authorities reach a different view, we will designate an Art 27 representative and update this section before the change takes effect. Our assessment is kept under review and the grounds are available on written request.

Contact and changes to this policy

Contact channels and change-management rules are stated explicitly so there is never ambiguity about how to reach us or how a change takes effect.
  • Privacy contactprivacy@truealter.com
  • Postal correspondenceRegistered postal address available on written request to privacy@truealter.com
  • Material changesWe notify you by email and by in-product notice at least 14 days before a material change takes effect. Where a change expands how we use your personal data or introduces a new data-sharing practice, we request a fresh consent rather than relying on the prior grant.
  • Non-material changesWe update the version line at the top of this policy and post the revised version. The prior versions are retained in the audit log.
  • Version historyAvailable on request; every version is hash-chained and cryptographically signed.

Continued use and deletion

Your continued use of the service after a material-change notice indicates acceptance of the updated policy. If you do not agree, you can delete your account at any time by running "alter forget" from the command-line client, or, if you have lost access to it, by writing to privacy@truealter.com.