DEMI Publishing Pipeline — Technical Brief

Registration of intellectual works by cryptographic fingerprint, with two payment rails and a public registry

Skydle · UplitAU Pty Ltd · ABN 91 680 646 495 · Sydney, Australia Version 1.0 · 26 August 2026

---

0. Status of this document, in one paragraph

The technical work is substantially complete and independently verified. Registration by card payment and registration by Ethereum transaction hash both function end to end and have both produced permanent, publicly readable records whose cryptographic evidence has been reproduced from the original files by a third party. What is not resolved is legal, not technical. This brief sets out what was built, how it works, what has been proved, what remains imperfect, and what a publishing company needs in order to run it. It is written to be read by a solicitor, by a publisher, and by that publisher's IT or AI consultant — the last of whom should be able to read it, ask their own AI system about it, and answer the question can we deploy this? without a further meeting.

---

1. What DEMI does, precisely

A registration answers one question and no others:

Did a file with this exact content exist at this time, and was it entered in a public register?

It does not establish authorship, ownership, identity or legal right, and the system says so on every artefact it issues. That restraint is deliberate and it is the reason the claim survives scrutiny: the system asserts only what arithmetic can support.

Around that evidential core the pipeline adds three things that are useful rather than evidential:

1. A Conceptual Core — a five-part structured statement (Core Statement, Propositions, Constraints, Mechanisms, Boundaries) generated by a language model from an author-selected extract. This is what makes a registered work usable by an AI system rather than merely provable.
2. A portable identifier — the UPL registry code and the DEMI Activation Reference that wraps it, readable by both humans and machines.
3. Publishing outputs — free EPUB and Word conversion, performed in the browser, explicitly outside the evidence chain.

The commercial observation behind the design is uncomfortable but true: people do not pay for evidence of existence. They pay for something to be done with the work. The evidence is what is true; the Conceptual Core is what is wanted. The architecture sells both and lets the payment method decide which is published.

---

2. Two platforms, one code — the referral concept

DEMI was developed in working sessions with two AI systems, and the design reflects that.

Claude (Anthropic) was used to design and write the registration interfaces, the Worker, the certificate and landing-page generators, and the analytical documents. Claude also performs the Conceptual Core extraction at registration time, through the Anthropic API called server-side by the Worker.

ChatGPT (OpenAI) hosts the DEMI Portal Builder, a Custom GPT in the GPT Store. An author who has registered a work can take the AI Publication Package to that GPT and have it build a conversational portal around their own registered ideas.

The bridge between them is the registry code itself — an ordinary text string with no platform allegiance, no payment data and no identity claim:

UPL-TECH-26-100284-EN                    the registry code
DEMI:1042:UPL-TECH-26-100284-EN:O        the Activation Reference wrapping it

The Activation Reference is purely additive. The registry code appears inside it byte-for-byte, so any system already matching UPL codes continues to match. The final character is an ISO 7064 MOD 37,36 check character — the scheme used by ISNI and GRID — so a mistyped reference fails validation rather than silently resolving to a different work.

Both platforms validate the same format with one regular expression:

^(DMX|UPL)-[A-Z0-9]{3,6}-\d{2}-\d{4,6}-[A-Z0-9]{2,4}$

The practical effect is that one identifier appears in three places — the Claude-built interface output, the public Registry, and the GPT portal page. A reader who encounters the work in any of them can resolve it in the others. Adding a further platform namespace requires one more prefix in the same expression.

Neither Anthropic nor OpenAI is a party to this, has endorsed it, or has been asked to do anything. The bridge works because the code format is deliberately trivial. That is the point: a standard that requires cooperation from two competing platforms will never exist; a standard that requires nothing from either can be adopted unilaterally by anyone.

For a publisher, the referral logic matters commercially. An author arrives with a manuscript, receives evidence and a Conceptual Core, and leaves with an identifier that lets any AI system engage with their ideas. The publisher is the door; the registry is neutral ground that no platform controls.

---

3. What has been proved, and how it was checked

The following verifications were performed on 26 August 2026 by an independent process — an AI system with no access to the interfaces, recomputing SHA-256 from the original uploaded files and comparing against the values printed on certificates and stored in the live Registry.

3.1 Card rail — three tiers, one session, 25 August 2026

Tier	Registry code	Source file hash	Extract hash
Starter A$9	UPL-TECH-26-851230-EN	match	match
Author A$29	UPL-TECH-26-109077-EN	match	match
Publisher A$99	UPL-TECH-26-519136-EN	match	match

Six of six independent hash reproductions. Every extract was UTF-8, NFC-normalised, no byte-order mark, no trailing newline — the properties required for a third party to reproduce the digest without guessing at encoding.

3.2 Ethereum rail — real transaction, verified four days later

Field	Value
Registry code	UPL-TECH-26-100284-EN
Registered	22 August 2026, 12:54 UTC
Environment	real
Payment	eth
Transaction hash	0xbedeff0aaac1e4150400811c1485ca6dc7d89ef017d9e77741664dd482f67355
Amount	0.0035 ETH
payment_verified	true
File	23.8 MB DOCX
Stored file hash	904b3fe9613aa7ae8aa600cd7c2550f133b2bafd38e9afa2ca22e8c39d45a6ae
Recomputed 26 Aug from the original file	identical

This is the material fact of this brief. A work was registered against a real Ethereum transaction on 22 August. Four days later, on a different machine, from the original file, the fingerprint was reproduced exactly and matched the record served by the live Registry. The transaction hash is on the public Ethereum ledger and can be inspected by anyone, without the cooperation of UplitAU, now or after UplitAU ceases to exist.

3.3 Non-English handling

An earlier registration in Russian (UPL-TECH-26-100730-RU) was verified the same way. Its extract reproduced exactly in NFC form; the NFD form of the identical visible text produces a completely different digest (3590a67a… versus 3a24aeb4…). Unicode normalisation is applied at every capture point for this reason. Cyrillic, accented Latin and CJK titles are handled.

3.4 How any reader can repeat this

No account, login, permission or trust in UplitAU is required:

# 1. Compute the fingerprint of the original file
sha256sum WORK.docx

# 2. Fetch the public record
curl https://demi-proxy.flat-bonus-ffc5.workers.dev/registry/UPL-TECH-26-100284-EN.json

# 3. Compare file_sha256. Compare extract_sha256 against
#    sha256sum of the downloaded Frozen Extract .txt

# 4. For an ETH registration, inspect payment_ref on any
#    Ethereum block explorer

The verification costs nothing and depends on nothing except the arithmetic of SHA-256 and the persistence of the public blockchain.

---

4. Architecture

4.1 Division of trust

┌──────────────────────┐
│  AUTHOR'S BROWSER    │  holds no secrets
│                      │  · SHA-256 via Web Crypto API
│                      │  · DOCX/PDF → EPUB locally
│                      │  · sends ONLY the chosen extract
└──────────┬───────────┘
           │ HTTPS POST — extract, metadata, hashes, payment ref
           ▼
┌──────────────────────┐        ┌────────────────────────────┐
│  CLOUDFLARE WORKER   │───────▶│  ETHERSCAN API             │
│  "demi-proxy"        │        │  did the ETH reach OUR     │
│  the gatekeeper      │◀───────│  address? amount? status?  │
│                      │        └────────────────────────────┘
│  · API keys as       │        ┌────────────────────────────┐
│    encrypted secrets │───────▶│  LEMON SQUEEZY API         │
│  · enforces rules    │◀───────│  paid AUD order for this   │
│    SERVER-SIDE       │        │  email, ≥ amount, unrefunded│
│  · browser cannot    │        └────────────────────────────┘
│    bypass it         │        ┌────────────────────────────┐
│                      │───────▶│  ANTHROPIC API (Claude)    │
│                      │◀───────│  Conceptual Core from the  │
└──────────┬───────────┘        │  extract only              │
           │                    └────────────────────────────┘
           ▼
┌──────────────────────┐
│  CLOUDFLARE KV       │  namespace DEMI_REGISTRY
│                      │  rec:{UPL}        one record per work
│                      │  tx:{hash}        spent ETH transactions
│                      │  order:{ref}      spent card orders
│                      │  _index           light public index
│                      │  _anchors         registry anchor history
└──────────┬───────────┘
           ▼
   PUBLIC READ ENDPOINTS — open to every human and every AI system
   /registry/index.json · /registry/{UPL}.json
   /certificate/{UPL}   · /registry/{UPL}/index.html

Browser = fingerprints. Blockchain = time and payment. Worker = rules. KV = storage. Public = anyone verifies.

4.2 The manuscript never leaves the device

This is the property that most affects a publisher's risk position, so it is worth stating precisely. The file is read with the FileReader API and hashed with crypto.subtle.digest('SHA-256', ...) inside the browser. Only the following are transmitted:

• the extract the author selects (capped at 12,000 characters)
• the metadata the author types
• the two computed hashes
• the payment reference
• the author's email address (stored, but stripped from every public response)

UplitAU never receives the manuscript, cannot produce it on request, and cannot disclose it under compulsion, because it does not have it. A publisher deploying this holds no author manuscripts either.

4.3 Request modes

The Worker is a single serverless function dispatching on a mode field:

Mode	Purpose	Auth
extract	Suggest a representative passage from full text	none
(default)	Generate the five-part Conceptual Core	none
verify_fiat	Check a paid Lemon Squeezy order exists	none
verify_eth	Check a transaction on-chain via Etherscan	none
register	Re-verify payment, allocate code, write record	payment
anchor	Record an on-chain anchor of the whole Registry	wallet

Read endpoints (GET) are public by design and CORS-open to *. Write endpoints are CORS-restricted to the configured origin, which is a convenience rather than a control — the substantive protection is that register independently re-verifies payment before writing anything.

4.4 Server-side enforcement — what the browser cannot bypass

Read directly from the deployed Worker source. This is the part an IT consultant should examine most closely, because it determines whether the register can be gamed.

Payment is re-verified at registration, not merely at the verify step. A caller who skips the interface entirely and POSTs a register request still triggers a fresh Etherscan or Lemon Squeezy lookup:

if (rec.payment === 'eth' && rec.payment_ref) {
  const used = await env.DEMI_REGISTRY.get('tx:' + rec.payment_ref.toLowerCase());
  if (used) return json({ ok:false, error:'This transaction has already been used to register ' + used });
  const ver = await verifyEthOnChain(env, rec.payment_ref, body.expectedAud || 9, body.ethRate || 2330);
  ...
}

Payment references are burned. On success the Worker writes tx:{hash} or order:{ref} into KV pointing at the registration that consumed it. A second attempt with the same transaction or order is refused by name. One payment, one work.

The ETH check is substantive, not a format check. It confirms the transaction exists; that tx.to equals the business address; that it is included in a block; that the value in wei meets the required amount; and that the receipt status is 0x1 — a confirmed-but-reverted transaction is refused, because no funds actually moved.

The card check is substantive. It queries the Lemon Squeezy API for orders on that email, and requires status === 'paid', not refunded, currency AUD, and total in cents at or above the expected figure. The order reference written into the record is the one the payment provider returned — not whatever the browser claimed.

Registry codes cannot collide. The browser proposes a code; the Worker checks rec:{UPL} and increments the serial until a free one is found, then returns the code it actually used. The interface adopts the returned value.

Email is stripped from public output. publicRecordView() removes the email field before anything is served from /registry/{UPL}.json, the certificate, or the hosted landing page. The full record remains in KV for operational use.

Environment labels are honest, and separate from payment truth. Three distinct states — real, test, demo — plus an independent boolean payment_verified. A real registration is refused outright if payment cannot be verified. A verified ETH payment is promoted to real regardless of the label requested, because on-chain evidence is stronger than a browser's assertion. A verified card payment is deliberately not promoted, because Lemon Squeezy has not yet been approved for production use here. That asymmetry is intentional and documented in the source.

A published test hash is permanently blocked. One transaction hash that appeared in public documentation is hard-coded onto a denylist so it can never be presented as payment.

4.5 Registry anchoring

Beyond individual registrations, the whole Registry can be anchored. The Worker computes a digest over the current index, stores it as a snapshot, and accepts an Ethereum transaction whose data field carries that digest. It verifies the digest matches a known snapshot, that the sender is the configured anchor wallet, and that the receipt succeeded.

The effect is that the state of the entire register at a moment in time is fixed on a public ledger. If any historical record were later altered, the anchored digest would no longer reproduce. One anchor is currently recorded, at block 25556256.

A practical note worth recording: MetaMask refuses data-carrying transactions addressed to one's own accounts, as a phishing guard. The anchor is therefore addressed to the standard Ethereum burn address, which accepts data. Value is zero, so nothing is lost; the Worker validates the sender and the data payload, never the destination.

---

5. The two payment rails, and why they publish different things

This is a design decision with a legal rationale, and it is the part most likely to interest a solicitor.

The risk that matters is publication, not payment. An unidentified payment is a minor problem. Publishing a statement of a person's ideas, under UplitAU's name, on behalf of someone no institution has identified, is a larger one.

	Card	Ethereum
Who identified the payer	The card issuer, before DEMI was involved	Nobody
Registry entry	code, title, date, hashes, extract	code, title, date, hashes
Conceptual Core	published	not published
Core supplied to the registrant	yes	yes
Evidence quality	identical	identical

Where the Core is withheld it is not transmitted to the Registry at all — the transmitted record replaces it with an explicit withheld marker and a stated reason. What is never sent cannot later be exposed by a breach, a subpoena or a mistake. The registrant still receives the full Core in their own downloads and remains free to publish it themselves anywhere.

The evidential value is the same on both rails. The payment method changes what is published, not what is proved.

---

6. Deployment — what a publisher needs

Two models exist. The distinction determines almost everything about cost and effort.

6.1 Model B — licensed deployment into the shared Registry (recommended)

The publisher runs no server infrastructure at all. They host one HTML page. All registry writes go to the central Worker and KV operated by UplitAU as namespace authority.

What the publisher provides:

Requirement	Specification
Web hosting	Any host that can serve one HTML page with an inline <script>. Squarespace, WordPress, Wix, Webflow, S3, GitHub Pages, or a company CMS. No server-side language required.
TLS	HTTPS mandatory. crypto.subtle is unavailable on insecure origins and the interface will not function over plain HTTP.
Payment account	Their own merchant account if they wish to charge (Lemon Squeezy, or any provider whose API can be queried for a paid order). Or none, if authors pay only the network fee.
Configuration	One block at the top of the file: namespace prefix, registrant name, tier prices, checkout URLs, environment label. Nothing below that block needs editing.
Skills required	Ability to paste an HTML block into a page and edit a dozen configuration lines. This is a web editor's task, not a developer's.
Deployment time	Under an hour, most of which is the payment account.
Ongoing cost	Hosting only.

Client-side requirements for the author's browser:

Requirement	Detail
Browser	Any modern browser supporting the Web Crypto API — Chrome, Edge, Firefox, Safari, from roughly 2018 onward.
JavaScript	Required.
Bandwidth	Trivial. The manuscript is never uploaded. A registration transmits a few kilobytes.
Local processing	Hashing and EPUB conversion are CPU-bound in the browser. A 24 MB DOCX hashes in well under a second on ordinary hardware; a large PDF text extraction is the slowest step, typically a few seconds.
Libraries	Loaded on demand from a public CDN: mammoth (DOCX), pdf.js (PDF), JSZip (EPUB). No installation.

6.2 Model A — publisher runs their own Worker and KV

Only necessary if the publisher requires their own separate register rather than a shared namespace. It fragments the standard — ten publishers, ten registries, and the ISBN-equivalent claim weakens — but it is technically supported.

Component	Requirement
Platform	Cloudflare account. Workers + KV. No virtual machine, no container, no operating system to maintain.
KV namespace	One, bound to the Worker as DEMI_REGISTRY
Secrets	ANTHROPIC_API_KEY, ETHERSCAN_API_KEY, LEMON_API_KEY (encrypted, server-side only, never exposed to the browser)
Variables	ALLOWED_ORIGIN; optional ANCHOR_WALLET
Worker size	The current Worker is a single file well within the 3 MB free-plan limit
Deployment	Paste the file into the Cloudflare editor and deploy. No build step, no bundler, no CI required.

Capacity, from published Cloudflare limits (verified 26 August 2026):

Limit	Workers Free	Workers Paid (from US$5/month)
Requests	100,000 / day	No published cap
Requests per second	No published cap on either plan	—
CPU time per request	10 ms	30 s default, up to 5 min
Memory	128 MB	128 MB
Subrequests per request	50	10,000
KV reads	~100,000 / day	10 M / month included
KV writes	1,000 / day	1 M / month included
KV storage	1 GB	1 GB included
KV maximum value size	25 MB	25 MB

What this means for registration throughput. One registration consumes:

• 1 Worker request for the Core generation, 1 for verify_*, 1 for register (3 requests)
• within register: 2–3 subrequests (Etherscan or Lemon Squeezy), well under the 50-subrequest free-plan ceiling
• 3 KV writes: rec:{UPL}, tx: or order:, and _index
• a handful of KV reads

The binding constraint on the free plan is KV writes, not requests. At three writes per registration, 1,000 writes/day is a practical ceiling of roughly 300 registrations per day — about 12 per hour sustained, far more in a burst. That is comfortably beyond a single publisher's realistic volume. The US$5/month paid plan raises this to roughly 330,000 registrations per month on included quota alone.

The real scaling limit is the index, and an IT consultant should know it. _index is a single KV key holding an array of every record. Each registration reads it, parses it, appends one entry of roughly 250 bytes, and rewrites the whole thing. Consequences:

• The 25 MB value ceiling implies a hard maximum around 100,000 records.
• Long before that, the 10 ms free-plan CPU budget is exhausted parsing and re-serialising a large index. Expect the free plan to become unreliable in the low thousands of records; the paid plan's 30-second budget removes this concern in practice.
• The rewrite is not transactional. Two registrations completing in the same instant could interleave and lose one index entry. The record itself is unaffected — it is written under its own key — so no evidence is lost, but the index could under-report.

If a licensee expects volume beyond a few thousand records, the index should be sharded — for example by year and category, _index:2026:TECH — or replaced with a paginated listing built from KV list(). This is a contained change to two functions and does not touch the evidence model. It is the single most valuable engineering improvement available to a future developer.

6.3 External dependencies and what happens if they fail

Dependency	Used for	If unavailable
Cloudflare Workers + KV	Rules and storage	Registration halts; existing records unreachable until restored
Etherscan API	ETH verification	ETH rail halts. Card unaffected
Lemon Squeezy API	Card verification	Card rail halts. ETH unaffected
Anthropic API	Conceptual Core	Registration proceeds; the interface falls back to a first-sentence Core and the record notes it
CDN (cdnjs)	mammoth, pdf.js, JSZip	Conversion fails with a clear message; hashing still works
Ethereum network	Anchoring and ETH payment	Anchoring pauses; existing anchors remain permanently verifiable

The important property: no dependency failure can invalidate an existing registration. The evidence is a hash and a timestamp, already written. A person holding the original file and a certificate can demonstrate the match with the sha256sum command on their own computer and no network at all.

---

7. Known technical imperfections

Stated plainly, because a brief that claims completeness invites the discovery that it was not complete.

1. The expected price is supplied by the client. register accepts expectedAud from the request body (body.expectedAud || 9) and compares the payment against it. A caller bypassing the interface could submit a low figure and have a trivial payment accepted. The fix is a server-side product table keyed by tier so the Worker derives the price itself. This is the one defect that should be corrected before any production launch, and it is perhaps thirty lines of code.

2. Title screening is a placeholder. The blocked-terms list contains two dummy strings and nothing else, and it is client-side, so it is bypassable in any event. Screening of the title and the extract belongs in the Worker before the write. Content of the manuscript cannot be screened at all, by design, because it is never received — a limitation the terms state openly.

3. The ETH rate is a fixed constant in the page. The interface computes the requested ETH amount from a hardcoded rate, and passes that rate to the Worker, which trusts it. The on-chain amount check applies a deliberate 10 % tolerance for price movement, so short-term drift is absorbed, but the rate should be fetched from a price oracle server-side.

4. Store currency. All three tier products are currently denominated in USD and converted at checkout, which causes the AUD total to land a cent either side of the advertised price. A A$99.00 tier invoiced at A$98.99 was refused on 25 August for exactly this reason; a five-cent verification tolerance now absorbs it. The correct fix is to price the products in AUD.

5. Tier billing basis. The Author and Publisher tiers are presently configured as monthly subscriptions in the payment store while the interface describes a one-off registration of a single work. This must be reconciled before either tier is sold. The Starter tier is a one-off charge and is unaffected.

6. Registrant attribution. The publisher-edition build names a licensee as registrant in the certificate while payment is taken by UplitAU. Correct for a genuine licensee deployment; it must be set to match the entity actually operating each instance.

7. Administrative tools are partly built. A Registry backup and archive-comparison tool is complete and working — it is read-only, needs no credentials, and produces a full archive with a per-record and whole-archive SHA-256 manifest, plus a comparison function that flags the one event that must never occur in a tamper-evident register: a hash that differs between two archives. Void/supersede and correct/withdraw interfaces are written but await two Worker endpoints (mode: "void", mode: "amend") with server-side token verification. They fail closed until those exist. A future developer working with an AI assistant could complete them in a session; the design decisions are already documented.

8. EPUB output is EPUB-3 only, with no NCX fallback for older readers. It is a publishing convenience and explicitly outside the evidence chain.

None of these affects the evidential claim. Every one of them sits in the commercial or operational layer around it.

---

8. The legal question, narrowed to one

The technical work has reached the point where the remaining obstacle is not engineering.

R1 — May UplitAU Pty Ltd receive Ethereum directly from a registrant, as the fee for registering that registrant's own work, without thereby carrying on a business that requires registration as a digital currency exchange provider under the AML/CTF regime — yes or no; and if yes, on what conditions?

The question is narrow deliberately. It is not a request for general advice on the concept. The relevant facts are these:

• The recipient is the registrant's counterparty, not an intermediary. UplitAU receives value in exchange for a service it performs itself. It does not exchange currency for anyone, does not hold value on anyone's behalf, and does not transfer value between third parties.
• The amount is small and fixed, denominated in AUD and converted at the point of payment.
• The transaction is between the registrant's own wallet and a wallet controlled by UplitAU. Both are visible on a public ledger.
• The Conceptual Core is deliberately not published for such registrations, precisely because no institution has identified the payer.
• The rail is presently suspended for public use and confined to a password-protected page, pending this advice.

A "no" ends the Ethereum rail. That is an acceptable answer: the card rail is proved and the evidential claim does not depend on the payment method. But the transaction-hash registration is the more interesting half of the concept — it is the part that makes a record verifiable without the registry's cooperation and durable beyond the registry's own existence — and removing it would postpone that line of development indefinitely.

An institution reading this brief and reaching a different view is invited to put the same question to its own advisers. The design is published openly, and a publisher who obtains a favourable answer in its own jurisdiction may deploy it under its own name and its own terms.

---

9. What a publisher can do today

Available now	Status
Card-paid registration, three tiers	Proved end to end, test mode
Ethereum-paid registration by transaction hash	Proved end to end, real transaction, suspended pending R1
Free DOCX/PDF → EPUB and Word conversion	Working, no payment, no registry entry
Five-part Conceptual Core, multi-language	Working
Certificate, Frozen Extract, machine-readable record, landing page, AI Publication Package	Working, all issued in one session
Hosted landing page at a stable URL	Working
Public registry, human and machine readable	Live
Registry-wide anchoring to Ethereum	Working, one anchor recorded
Registry backup with tamper detection	Working
Void / correct / withdraw	Interfaces built, Worker endpoints outstanding

A publisher wishing to evaluate the system needs no agreement and no infrastructure: open the interface, register a work, download the artefacts, and reproduce the hashes with a single command. The verification either works or it does not, and it does not require believing anything anyone says.

---

10. For an AI or IT consultant reading this on a publisher's behalf

This section exists so that this document can be handed to another AI system with the question is this real, and can we run it?

The claim to test. That a file's SHA-256 fingerprint and a selected extract's SHA-256 fingerprint, recorded with a timestamp in a publicly readable store, allow any third party to demonstrate that a specific byte-sequence existed at a specific time — with no trust in the operator beyond trust in SHA-256 itself.

How to falsify it. Take any registered work. Recompute both digests from the original file and the downloaded Frozen Extract. If they do not match the record, the claim fails. If an ETH-paid record's payment_ref does not appear on the public Ethereum ledger with the stated amount to the stated address, the claim fails. Both checks are available to anyone at zero cost.

What the system does not claim, and where a consultant should resist over-reading: it does not prove who wrote the work, who owns it, or that anything was lawful. A person registering someone else's manuscript produces a record that looks entirely valid. The register records an act of submission, not a right.

The specific technical facts that make it cheap. The 2019 predecessor of this design required deploying Solidity smart contracts and placing every participant on-chain — heavy, expensive, and ahead of both tooling and regulation. The present system replaces deployment with reading. Etherscan's API lets a Worker verify any payment or anchor by querying public chain state, with no contract to deploy, audit or maintain. Cloudflare's edge Workers and KV supply a globally distributed backend at effectively zero cost. The entire on-chain registration architecture reduces to a serverless function plus two read APIs. That substitution — verification by reading against public infrastructure, rather than bespoke on-chain deployment — is what made the standard achievable by a small organisation.

Where to look first in the code. The register handler in the Worker. It contains the whole trust model in about seventy lines: payment re-verification, reference burning, code uniqueness, environment labelling. If that function is sound, the register is sound. If a consultant wants to find a flaw, that is where it will be — and item 1 of section 7 tells you where the current one is.

Integration surface. Everything a downstream system needs is public JSON over HTTPS with permissive CORS:

GET /registry/index.json          all records, light form
GET /registry/{UPL}.json          one record, full public view
GET /certificate/{UPL}            human-readable certificate
GET /registry/{UPL}/index.html    hosted landing page, JSON-LD + OG tags

Landing pages carry schema.org CreativeWork JSON-LD with PropertyValue identifiers for the Activation Reference, the UPL code and the SHA-256, a rel="alternate" link to the JSON record, and a canonical link. An AI system encountering a landing page in the wild can resolve the registration without being told how.

---

11. Summary

The engineering is done to the standard that matters: the evidence chain has been reproduced independently, on both payment rails, in two languages, four days after the fact, by a party with no access to the system that created it.

What remains is a legal question with a yes-or-no answer, and a short list of operational imperfections that are documented above rather than concealed.

The design is published openly. Anyone may study it, replicate it, and deploy it under their own name, their own namespace and their own terms. A registry standard that only one organisation can operate is not a standard.

---

Skydle UplitAU Pty Ltd · ABN 91 680 646 495 · Sydney, New South Wales, Australia ramsmile@uplitau.com · ramsmile.com Australian Innovation Patents AU2018100999 and AU2019101249

AI co-development: Claude (Anthropic) for interface, Worker and document design and for Conceptual Core extraction; ChatGPT (OpenAI) for the DEMI Portal Builder. Neither organisation is a party to this work, has endorsed it, or has been asked to act. All verifications reported in section 3 were performed by recomputation from original files and comparison against the live public Registry.

This is a technical document. It does not constitute legal, regulatory or financial advice.