DEMI Publishing Pipeline

R10 Data handling and retention The uploaded manuscript is read inside the visitor's own browser. It is never transmitted to UplitAU, never stored, and no copy exists after the browser tab closes. The SHA-256 fingerprint is computed locally.

• What is transmitted and retained: the metadata typed below, and the Frozen Extract — a passage of the work chosen by the author.
• The Frozen Extract is published in the public Registry record, the Certificate and the Landing Page. It is not private.
• The author's email address is transmitted and stored in the Registry record.

For advice: whether the Privacy Act 1988 (Cth) APP obligations are engaged given that email addresses and author names are collected and published; and whether a Privacy Policy and Collection Notice must be presented before upload rather than at checkout.

R3 Authorship warranty — the core liability question DEMI cannot and does not verify that a registrant is the author of what they register. Nothing in the system establishes identity, authorship, ownership or copyright. Every document the system issues already carries that disclaimer in terms.

• The disclaimer tells the reader what the record does not prove. It is built and in place.
• The warranty below shifts responsibility for a false authorship claim onto the registrant. It is drafted but has not been settled by a lawyer.
• Acceptance is recorded in the registration payload with a UTC timestamp and the exact wording shown.

For advice: (a) is the warranty wording below sufficient to establish the registrant's responsibility; (b) does the disclaimer adequately protect UplitAU against a claim by a third party whose work was registered by someone else; (c) what take-down process must exist when a genuine author disputes a registration — see R5.

R4 Content screening — title only The system screens the title field only. Manuscript content is never inspected, because the manuscript never leaves the visitor's browser (R10). This is a deliberate design choice, not an oversight: content inspection would require retaining the work, which would defeat the privacy position.

• The current blocked-terms list is a short placeholder, not a maintained moderation library.
• The check is client-side and can be bypassed by anyone editing their browser. An equivalent server-side check does not yet exist.
• A registered title appears publicly in the Registry, on the Certificate and on the Landing Page, alongside the UplitAU name.

For advice: what standard of screening is required before UplitAU is exposed to liability for publishing a title that is defamatory, harassing, or unlawful; and whether a documented notice-and-takedown procedure is sufficient in place of pre-publication screening.

R2 Author and Publisher tiers — displayed, not built Only Starter exists as a working product. Author and Publisher are shown below so the intended commercial structure can be reviewed. Neither can be purchased here or on any live page.

• There is no user account of any kind in DEMI. Every registration is a stateless, anonymous, one-off transaction. The system cannot recognise a returning customer.
• Consequently there is no entitlement lookup and no usage counter. Author's stated "5 works per month" could not be enforced or displayed, and neither the customer nor UplitAU could answer "how many registrations have I used".
• No recurring billing products exist. A subscription taken today would bill monthly while delivering nothing after the first registration.
• Proposed direction: rather than sell subscriptions to the public, license the interface to publishing companies, each operating its own deployment, its own Worker and its own terms settled by its own advisers. UplitAU would then verify "this registration belongs to licensee X" rather than track thousands of individual consumers.

For advice: (a) whether the licensed-publisher model materially reduces UplitAU's obligations compared with direct consumer subscriptions; (b) what must appear in a licence agreement with a publishing company, particularly as to which party is the supplier to the end author, who holds the consumer-law obligations, and who is responsible for content published under a licensee's deployment.

R6 What the A$9.00 Starter fee actually buys The fee is for registration: a timestamped Registry entry, a cryptographic fingerprint of the file, an AI-generated Conceptual Core, and a set of downloadable documents. Three distinct uses follow from it, and none is currently explained to the customer before payment:

• Evidence only — the Certificate and Frozen Extract, kept by the author.
• Referral to an AI system — the AI Publication Package is designed to be pasted into a third-party AI tool such as the GPT Store. UplitAU does not control that platform and cannot guarantee its continued availability.
• Referral to a publishing company — a separate, separately-priced service offered by another entity.

For advice: what must be disclosed before payment under Australian Consumer Law, given that (a) the deliverable is partly dependent on a third-party platform, (b) the service is delivered immediately on payment, and (c) what refund position applies to a digital service already delivered.

R9 Merchant of record, GST and invoicing Card payments are processed by Lemon Squeezy, which acts as merchant of record and issues the tax invoice to the customer in its own name, showing its own GST registration. The customer's contractual counterparty on the invoice is therefore not UplitAU. For advice: whether this arrangement is correctly reflected in the Terms and Conditions; who the supplier is for Australian GST purposes; and whose refund and complaint-handling obligations apply to the end customer.

R1 Ethereum rail — AUSTRAC and identification The card rail is approved and operating. The Ethereum rail is not cleared for use and is the single most significant open question in this project.

• Payment is received directly to a wallet controlled by UplitAU, then off-ramped through CoinSpot, an AUSTRAC-registered exchange. It is not received by an intermediary on UplitAU's behalf.
• A card payment carries the payer's identity through the card issuer. A direct ETH payment carries no identification whatsoever. A registrant can supply any name.
• The disclosure shown in the black panel below was drafted in-house and has not been settled by a lawyer.
• Whether accepting cryptocurrency in exchange for a service makes UplitAU a digital currency exchange provider requiring AUSTRAC enrolment has not been determined. The relevant enrolment date has passed.

For advice, and this is the priority question: (a) does receiving ETH directly as consideration for a service constitute a designated service under the AML/CTF Act 2006; (b) if so, what enrolment, KYC and Travel Rule obligations follow, and what is the position given the date has passed; (c) is the drafted disclosure adequate, and (d) should the Ethereum rail be withdrawn entirely pending that determination.

R5 Correcting or removing a Registry entry Two different things are conflated by the word "remove", and they behave differently:

• The cryptographic evidence — the file fingerprint, and where ETH was used the on-chain transaction — is permanent by design. There is no mechanism to undo it, and that permanence is the point of the system.
• The Registry display record — the JSON entry, Certificate and Landing Page — is held in UplitAU's own storage and can technically be edited or deleted.

No correction or removal policy currently exists. The proposed approach is a visible "superseded" or "voided" status with a stated reason, rather than silent deletion, on the reasoning that a record quietly disappearing from a tamper-evidence system undermines the very claim the system makes. For advice: (a) what obligation exists to correct a record at the registrant's request; (b) what obligation exists to remove a record at a third party's request, for example a genuine author or a defamation complainant; (c) whether a visible "voided" status satisfies those obligations, or whether actual erasure is required; and (d) what record of the correction itself must be kept.

R7 Works by children — deliberately excluded A feature allowing a child to register a first creative work has been considered and deliberately excluded from this build. Children's personal information is separately and more tightly regulated — the Children's Online Privacy Code under the Privacy Act 1988 (Cth), and equivalents overseas including COPPA and the UK Age Appropriate Design Code — with requirements for verified parental consent, data minimisation and child-specific notices. For advice, at a later stage and not part of this review: what would be required before any registration by or on behalf of a person under 18 could be accepted. It is raised here only to record that it was identified and set aside rather than overlooked.

R8 Two-interface structure The intended structure separates two things that are currently mixed:

• This interface — UplitAU Pty Ltd. Starter only, A$9.00, one work, card payment. Simple, single-tier, no accounts, no subscriptions.
• A licensed interface — for publishing companies. Deployed by each company on its own infrastructure, under its own terms settled by its own advisers, managing its own author roster.

A deployment guide for this licensed model already exists and has been used once, for UplitPublishing Pty Ltd. For advice: what form the licence should take, and how to ensure that a licensee's obligations to its own authors do not attach to UplitAU as the supplier of the underlying tool.

Consolidated schedule — items for advice

• R1 · Ethereum, AUSTRAC and identification — highest priority. Whether direct receipt of ETH is a designated service; enrolment position given the date has passed; whether to withdraw the rail pending determination.
• R2 · Author and Publisher tiers — not built. Whether the licensed-publisher model is preferable to consumer subscriptions, and what a licence must contain.
• R3 · Authorship warranty — drafted, not settled. Sufficiency of the warranty and disclaimer against a third-party authorship claim.
• R4 · Content screening — title only, client-side, placeholder list. Required standard, and whether notice-and-takedown suffices.
• R5 · Correction and removal — no policy exists. Obligations to correct and to remove; whether a visible "voided" status is sufficient.
• R6 · Pre-purchase disclosure — three distinct uses of the fee, one dependent on a third-party platform. ACL disclosure and refund position.
• R7 · Works by children — excluded. Requirements before any under-18 registration could be accepted. Later stage.
• R8 · Two-interface structure — licence form, and separation of licensee obligations from UplitAU.
• R9 · Merchant of record — Lemon Squeezy invoices in its own name. Supplier identity for GST; whose refund obligations apply.
• R10 · Data handling — manuscript never transmitted; extract and email are published or stored. APP obligations, Privacy Policy and Collection Notice timing.

Existing intellectual property: Australian Innovation Patents AU2018100999 and AU2019101249. Registered payment approval: Lemon Squeezy, card rail, UplitAU Pty Ltd. No third party has yet registered a work through this system; all registrations to date are internal tests.