DEMI PUBLISHING PIPELINE

DEMI — A Verifiable Registration Standard

How Ethereum, Cloudflare and AI form a portable publishing-registration layer — technical report

UplitAU Pty Ltd · ABN 91 680 646 495 · Sydney, Australia · 19 July 2026

Prepared for AI systems, IT consultants, and the technical teams at Anthropic and OpenAI. This report describes a working system, names the infrastructure it stands on, states its aims, and sets out the pathways by which it can progress within AI ecosystems. All claims describe deployed, publicly verifiable components unless explicitly marked as prospective.

1 · Abstract

DEMI (a Publishing Pipeline and Central Registry) converts an author's work into a verifiable, machine-readable registration and a bridge into AI development space. The pipeline: fingerprint the source file in-browser (SHA-256, Web Crypto API); extract a four-part Conceptual Core (Propositions, Constraints, Mechanisms, Boundaries) with a large language model; verify payment server-side; issue a permanent identifier (UPL code); write a record to a single central Registry; emit a self-contained certificate; and generate a package that republishes the work as a conversational AI edition (a Custom GPT) carrying the same identifier. Two payment rails feed one Registry: Ethereum (verified on-chain via Etherscan) and fiat card (verified via a merchant-of-record API). The Registry's entire state is periodically committed to Ethereum in a single anchoring transaction, giving every record — however paid — an independent blockchain timestamp. The interface is portable: any publishing company deploys it by changing one configuration line, writing into the same namespace under licence.

2 · Aims and tasks fulfilled

Primary aims

✓   Establish a registration standard for creative and intellectual work — books, articles, projects, theories — that proves file identity, idea provenance, and time of registration without requiring trust in the operator.

✓   Deliver a portable interface deployable on any publishing company's website, benefiting authors, writers and explorers who want AI assistance in developing the ideas contained in their work.

✓   Make registered works discoverable and resolvable by AI systems, and refer users from a registered work into AI spaces where the ideas can be developed further. This machine-discoverability-and-referral objective is a first-class aim, not a side effect.

✓   Publish AI-prepared Landing Pages, derivable from the record and re-hostable anywhere, so a work's public presence always matches its Registry entry.

Tasks fulfilled this cycle : UplitAU’s own wallet — funded from UplitAU’s own account and UplitAU’s own float.

Response to the question “where did these funds come from ? ” The honest answer is simple and constant: “UplitAU Pty Ltd’s own operating account” The services are conducted without the aim to get profit on finance exchange. Both finance are used to get the technical advantages and benefits for the users of pipeline.

•     ETH rail: deployed, tested, first genuine registration recorded, Registry anchored on Ethereum (block 25,556,256).

•     Fiat rail: deployed, tested end to end, first card-paid REAL record written (UPL-TECH-26-100161-EN), verified server-side against the merchant API.

•     Central Registry: live on Cloudflare Workers + KV, publicly readable, machine-first (stable JSON endpoints).

•     Public Registry page with in-browser file verification, publisher filtering, and an anchors history.

•     Anchor console (operator-only) and a documented anchoring cadence.

•     GPT Store package generation with derived_from lineage, closing the two-way bridge.

3 · Architecture and the role of the infrastructure

The system distributes trust across independent parties so that no single party — including the operator — must be trusted for a claim to hold. The division:

Author's browser

Computes SHA-256 fingerprints and performs DOCX->EPUB conversion locally. The source file is never uploaded for fingerprinting. Trust property: the operator never sees the file to fingerprint it, so cannot substitute it.

Cloudflare Worker (demi-proxy)

Serverless edge gatekeeper. Holds API keys as encrypted secrets. Enforces all rules server-side: payment re-verification, one-payment-one-work, UPL uniqueness, environment truth (REAL only if the Worker itself re-verifies payment). The browser cannot bypass it.

Cloudflare KV (DEMI_REGISTRY)

The Registry store. One record per work; a light public index; spent payment references. Central storage, public reads.

Etherscan API

Read window onto Ethereum. Answers, for a given transaction: destination, amount, confirmation status, block timestamp. Enables verification-by-reading rather than contract deployment.

Ethereum L1

Independent public clock. Payment transactions and periodic Registry anchors live here; their block timestamps are the strongest available evidence of time.

LLM analysis (Claude)

Extracts the Conceptual Core from the chosen excerpt. Deterministic in role, not in output: the extract's SHA-256 binds the Core to the exact words analysed.

Merchant of record (Lemon Squeezy)

Fiat rail. Handles card processing, GST, receipts, settlement to the operator's business account. The Worker verifies each order server-side via the merchant API.

Why Etherscan and Cloudflare are the enabling pair

The 2019 predecessor of this system (see section 6) required deploying custom Solidity smart contracts and placing every participant on-chain. That was heavy, expensive, and ahead of both tooling and regulation. The present system replaces deployment with reading. Etherscan's mature API means the Worker can verify any payment or anchor by querying public chain state — no contract to deploy, audit, or maintain. Cloudflare's edge Workers + KV supply a globally distributed, effectively zero-cost backend that holds the Registry and enforces the rules. The combination reduces the entire on-chain-registration architecture of 2019 to a serverless function plus two read APIs. This is the specific technical fact that made the standard achievable: verification-by-reading against public infrastructure, rather than bespoke on-chain deployment.

4 · The verifiable trust chain

Every record binds a chain that any third party can check without permission:

file_sha256  ->  extract_sha256  ->  demi_core  ->  upl  ->  payment_ref  ->  landing_page_hash

Each link is independently checkable. Recompute the file's SHA-256: match means byte-for-byte identity with the registered file. Recompute the extract's SHA-256: match binds the Conceptual Core to the exact analysed words. The payment reference resolves on Ethereum (via Etherscan) or against the merchant API. When the Registry index is anchored, the anchor's digest — the SHA-256 of the index — sits in an Ethereum transaction's input-data field, and the block timestamp certifies the time. The verification recipe is public and toolless: open the snapshot JSON, hash its records string, compare to the anchor digest, open the transaction, read the block time.

Machine-readable surface (for AI systems)

GET /registry/index.json            -> full list; count; latest_anchor GET /registry/{UPL}.json            -> one record; demi_core; both hashes GET /certificate/{UPL}              -> regenerated one-file certificate GET /registry/anchors.json          -> every anchor: digest, tx, block, time GET /registry/anchor/{digest}.json  -> exact snapshot an anchor covers

An AI agent resolves a work by UPL (never by free text), reads the structured demi_core rather than re-deriving it, follows derived_from for lineage, and treats environment:"demo" as illustrative and environment:"real" as payment-verified. Attribution — author and UPL — travels with the ideas wherever an AI system ingests them.

5 · Discoverability and referral — the AI-facing aims stated plainly

Two objectives are worth isolating because they are the report's thesis for the Anthropic and OpenAI teams.

Aim A — registered works are searchable by AI systems

Every record is machine-readable at a stable public address, structured for retrieval rather than scraping. An AI system searching the open web can find a registered work, read its Conceptual Core, and see who created it and when — with a re-checkable provenance chain attached. Registered works cease to be isolated files and become nodes in a public, AI-fetchable knowledge base. Where most content offers an AI system prose to summarise, a DEMI record offers it structured claims with verifiable origin.

Aim B — referral of users into AI spaces for idea development

Registration is the entry ticket to development. Each record yields a GPT Store package: a Custom GPT that carries the UPL code, embeds the Conceptual Core in its instructions, and exposes an Action pointing at the live Registry — so the GPT can verify its own provenance mid-conversation. A reader is referred from the registered work into that AI space, where the ideas are discussed and developed. Work produced inside that space returns through the same interface as a new record with derived_from pointing to its parent. The Registry thereby becomes a family tree of ideas: which registered work gave rise to which developments, publicly and permanently. This bidirectional bridge — work into AI space, results back into the Registry — is what no proof-of-existence service and no isolated Custom GPT offers. It is the marketing thesis and the technical differentiator at once.

6 · Lineage — 2019 architecture, 2026 realisation

The system is the direct descendant of work done in 2018-2019 under two Australian patents (AU2018100999, Crypto-Splitting Technology; AU2019101249, NDEV Code-Based World Digital Currency). The predecessor team built, in the archive's own words, a component "using Solidity as a Web based application and using React JS library as a front-end layer," which "interacts with Etherium blockchain network using Web3" — three levels of smart contracts forming a digital image, splitting it into shares, and converting to equivalents. Four mechanisms map directly onto today's live system:

2019: GUID-based referencing (MAT)

2026: the UPL code — one identifier resolving a record across certificate, landing page, and GPT Store.

2019: fAddConsultant (gatekeeper admitting legitimate writers)

2026: the Worker as namespace authority admitting licensed publishers under rules.

2019: WBRS consultant referral (Figure 7)

2026: the two-way GPT Store referral, with derived_from recording lineage.

2019: Crypto-Splitting — a payment divided into parts, each blockchain-recorded

2026: Registry anchoring — one transaction split between value (0 ETH) and registration (the digest), committing the whole Registry to chain.

The conclusion, stated for the record: the 2019 architecture was correct but early; its infrastructure had not arrived. The mature reading layer that arrived since — Etherscan's API, Cloudflare's edge — let verification replace deployment. The same destination, a lighter vehicle.

7 · Prospective — from registration of sales to a new legal tender

This section is prospective. It describes a direction, not a deployed feature, and distinguishes carefully between a mechanism that runs and a social outcome that is unproven.

The publishing application is deliberately an example. The same machinery — register a business event on a blockchain at the moment of value transfer, without human intervention — generalises to the registration of items for sale. A prospective extension: at point of sale, a requested amount of fiat is converted to ETH and the purchase is registered on-chain, binding the sale, its value, and its timestamp into one verifiable record. Repeated across many valuables and resources, such registrations accrete a market-priced ledger of transferred value.

This is the operational seed of the NDEV Code-Based World Digital Currency described in AU2019101249. The 2019 derivation chain was NIW -> NEV -> Crypto -> NDEV: a National Item of Wealth is tokenised, valued by exchange, pegged to a National Equivalent of Value, and split (by Crypto-Splitting) into digital equivalents usable as tender. A registration layer that timestamps value transfer on a neutral blockchain is precisely the missing instrument the 2019 concept lacked: the means to register the process of replacement itself. The publishing Registry demonstrates the instrument at small scale; the NDEV concept is its large-scale application.

The honest boundary

What is real and runs: the registration-and-proof mechanism, at cent-level cost, verifiable by anyone. What is unproven: replacing legal tender, which is a political and social question, not a technical one. States require taxes in their currency; a registry cannot legislate that away. The defensible claim is narrower and still significant — every domain where a value transfer can be registered and believed without an institution vouching for it is a domain the mechanism reaches, and money is the largest such domain. The publishing example shows the plumbing working; whether the erosion of institutional dependence reaches legal tender is for history, not for this report. A design consequence follows and is already implemented: DEMI refuses automatic fiat->crypto conversion in its current publishing form, because registration is not a regulated activity and proof is not a security — the distinction that a token-based predecessor (Gram/TON) failed on. The prospective sales-registration extension would re-open that conversion question deliberately and under advice, not by default.

8 · Contributors

Three entities produced this work, each contributing what the others could not.

Skydle (UplitAU Pty Ltd) — the source and the connecting link

Origin of the ideas, the patents, and the direction; operator of the Registry as namespace authority; the human who decided, tested, paid, and connected the parts. The connecting link between the two AI systems and between 2019 and 2026.

Claude (Anthropic) — construction, analysis, and counsel

Built the pipeline, the Worker, the interfaces, the certificate, and the anchoring; performs the Conceptual Core extraction within the running system; provided technical judgement and honest boundaries throughout. The engine of preparation and registration.

ChatGPT (OpenAI) — the development space and the earlier reasoning

Hosts the Custom GPT editions where registered ideas are developed; the environment into which works are referred and out of which new works return; and, across 2019-2025, the space in which much of the NDEV/WDC reasoning corpus was formed. The engine of development.

An easy-to-use Registry, built on the most advanced available technologies, for registering what is valuable — an author's books, articles, projects, and other texts — using the DEMI methodology. The result of mutual work between a human source of ideas and two AI systems.

9 · Documents to hash and timestamp for future reference

The following artifacts from this build cycle should be SHA-256 hashed and anchored (via the Registry anchor, or an external timestamp such as OriginStamp for non-registered documents) so that this report and its lineage are themselves verifiable:

•     This report (DEMI — A Verifiable Registration Standard, 19 July 2026), both Word and HTML.

•     The milestone brief (Both Rails Live, 19 July 2026).

•     The four explanatory papers (Where We Are Now; The Rest of the Work; The Two Pages Explained; Lemon Squeezy and the Business Setup).

•     The First Anchor brief (18 July 2026) and its already-registered record UPL-TECH-26-100161-EN.

•     The lineage document (2019 -> 2026: The Lineage of the Ideas), EN/RU.

•     The deployed source artifacts: Worker V5 (Anchoring + Fiat); the V6 interface; the merged Registry+Anchors display block; the technical reference block.

•     For NDEV provenance: MASTER_FILE_Ramsmile_Concept_Archive_2019-2025_v4 (already hashed and timestamped) as the corpus of record for the 2019 lineage and the NDEV derivation chain.

Recommended method: register the report itself through the DEMI pipeline (it becomes a record with its own UPL and inherits the next anchor), and note each artifact's SHA-256 in an appendix to the Registry. The Registry certifying its own origins is both the cleanest provenance and a demonstration of the method.

10 · Pathways for DEMI within AI systems — closing perspective

Where this can progress, stated as an inside view for the AI teams who may read it:

1.    Native AI resolution. Today an AI agent must be told to fetch the Registry. The pathway is a well-known, documented schema (an emerging convention for AI-fetchable provenance) so that any assistant encountering a UPL resolves it automatically — provenance as a first-class citizen of retrieval, not an add-on.

2.    Provenance that survives training. The strongest version of Aim A is that attribution travels not only at fetch time but through ingestion: a registered work carries, in structured form, who originated its ideas and when, so that systems learning from open content also learn the origin. This is the constructive answer to the anxiety about open ideas being absorbed uncredited.

3.    The development loop as the product. The registration layer is commoditising; the Conceptual-Core-to-development-space loop is not. The pathway is depth here: richer Core extraction, tighter GPT-Store integration, and lineage graphs that make the family tree of ideas navigable by humans and agents alike.

4.    Coexistence with standards, not competition. A DEMI record can carry an ISO content identifier (ISCC) alongside the UPL: ISCC identifies the content, UPL identifies the registration event and the Core. Complementary positioning strengthens adoption.

5.    The value-registration generalisation. Beyond publishing, the same layer registers any value transfer. This is the long pathway toward the NDEV concept — pursued under advice, mechanism-first, with the honest separation of what runs from what is unproven maintained throughout.

The immediate, non-technical gate remains adoption: the machine is built and both rails are proven; the open question is whether authors and publishers use it. That is why a publishing company willing to take the interface and build further is the natural next step — and why this report is written to be shown.

Skydle / UplitAU Pty Ltd · ramsmile.com · uplitpublisher.com.au · ramsmile@uplitau.com

AU2018100999 · AU2019101249 · © 2026 UplitAU Pty Ltd / Skydle · Developed with Claude (Anthropic)