REZET HUB

Technical Architecture

Prepared by Duc Nguyen, Chief Technology Officer & Technical Co-Founder

Version 1.5 · July 2026

Document Purpose

This document describes the engineering strategy behind REZET HUB. It explains:

• what will be built,
• why the architecture has been chosen,
• how the platform achieves trusted provenance,
• how delivery will be governed,
• how investment funds will be used,
• and what technical risks remain.

It is written to give investors, technical advisers and due-diligence reviewers enough to judge that the solution is well designed, while staying readable without an engineering background. It presents the high-level technical layout (how the major components fit together) without the implementation detail carried in the full Technical Scope of Work. Commercial strategy and funding terms are presented separately in the Investor Brief; the numbers are owned by the Statement of Work v1.5.

Executive Summary

Engineering objective. This investment transforms an existing architectural foundation into a production-ready provenance platform capable of supporting trusted Digital Product Passports.

The platform records every significant event in a material's lifecycle, protects those records against undetected alteration, and turns that evidence into audit reports, regulatory documentation and consumer-facing Digital Product Passports. The engineering outcome is not simply another software platform. It is a proof engine: the audit trail itself is the product.

Where the build stands (30 July 2026). Substantially more of this architecture exists in code than the original plan assumed at this point: the identity vault, the full custody chain, hash-chaining, mass-balance accounting and the external public anchor all build cleanly today, each capability traceable to a merged, independently gated commit (see the Build Progress Report). On 30 July the core provenance path was additionally validated running end to end on the local development stack: collection to sealed product to public passport, with chain-computed impact. No milestone is claimed as accepted beyond M0: acceptance requires the live staging demonstration and independent review described under Delivery Governance.

Platform Vision — the Chain of Trust

Every arrow above is a moment where custody or state changes hands: material is collected, moved, processed or certified. At each of those moments the platform writes a permanent event: who (as an anonymous token), what, when, and the evidence attached. Those events are never edited or deleted; corrections are written as new events.

Every transition creates permanent evidence. The Digital Product Passport at the end of the chain, and every audit report along the way, are simply views assembled from that permanent record. Identity sits to one side of the flow, issuing anonymous tokens into it so that no personal data ever enters the record. The record is the product.

Design Principles

Before the technology, the philosophy: four principles govern every decision.

Trust before features. Every engineering decision is made against one question: can this information still be trusted years later?

Evidence before reporting. Reports are not typed in by hand. They are generated from trusted evidence, so every figure traces back to a recorded fact.

Privacy by design. Personal information is deliberately separated from provenance information, so audit history and privacy obligations can coexist rather than compete.

Build once, expand many times. The first deployment targets textiles, but the core is material-agnostic and scales from a regional pilot to the world: new materials and new regions are added, never rewritten.

Platform Architecture

The shape of the system

REZET HUB is built as a seam-respecting modular monolith: one deployable system today, assembled from independent components with firm boundaries, so any component can later be split into its own service mechanically rather than through a rewrite. This is the commercially load-bearing decision: the lean pilot platform and a later global-scale build are the same codebase maturing, not two projects.

Three well-established patterns combine, each applied only where it earns its cost:

• Domain-Driven Design draws the seams: the business already announces its natural components (generator, logistics, recycler, compliance, passport, plus a supporting identity registry).
• CQRS (separating the write path from read-optimised views) is used wherever reads and writes have different shapes: most visibly, the public passport is a read view scaled independently of the write side.
• Event Sourcing (storing state as an append-only log of facts, rather than overwriting rows) is used only in the provenance components, where the log genuinely is the source of truth. Supporting components use conventional storage. A heterogeneous system is correct here by design.

The four layers

Identity Layer: protect personal information. The single home for personal data. It issues the anonymous tokens every other component uses, stores each person's data encrypted under their own key, keeps data in the region the law requires, and makes erasure possible without touching the historical record.

Provenance Engine: an immutable history of every material. The heart of the platform: an append-only record of each batch from first collection to documented outcome. It records events as they happen, maintains the chain of custody as material changes hands, and can replay any batch's full history to reconstruct exactly what was known at any point in time.

Compliance Layer: turn history into evidence. From the same permanent record it produces audit exports, compliance reports and regulator-ready documentation, continuously, rather than as a manual scramble before each audit.

Digital Product Passport: public transparency. The public face of the record: scanning a product's QR code opens its origin, processing history and verified sustainability information, assembled from the provenance record, carrying no personal data by construction, and served from a fast, globally cached read layer that never touches the authoritative record.

How the components fit together

A batch's life is owned slice-by-slice across bounded contexts, each in its own private store, passing a small "baton" of integration events as custody moves. Identity stands to the side, issuing tokens into every context so the record carries references, never names.

Each component uses the storage that fits: the heavy event-sourced machinery only where the record itself is the product, conventional storage everywhere else. Contexts never read each other's stores; they communicate only through a small, versioned set of integration events, the single cross-component contract that keeps the monolith splittable and the audit honest.

How the rules stay enforced

The disciplines that make the proof audit-grade (each provenance context in its own append-only store, personal data quarantined to opaque tokens, and read views split by audience so residency stays cheap) are enforced by automated build checks, not good intentions: a change that violates them fails the build before it can ship. The complete rule set, the enforcement machinery behind each rule, and the honest enforced-versus-convention status are set out in the companion document Development Standards and Enforcement; the full engineering detail is in the Technical Scope of Work.

Technology foundation

Built on mature, widely-used open technology (an event-sourcing engine over PostgreSQL, orchestrated with .NET) that the CTO already owns as prior work, in the repository today. The public frontend is static on the Cloudflare edge; the backend runs behind a Cloudflare Tunnel with no public listener. Every external dependency (AI, storage, payments, email) sits behind a swappable adapter, so changing provider is a configuration change, never a code change and never a touch to the proof engine. No vendor name appears in the core (enforced by an architecture test), and there is no lock-in to any single cloud. (Specific stack versions are in the engineering Scope of Work.)

Trust Architecture

This is the core of the platform. Each guarantee is explained below, with a diagram.

Append-Only Recording

Most business software stores only the current state of things: when a record changes, the old value is overwritten and gone. REZET HUB uses event sourcing: the system stores the full sequence of events (batch collected, custody transferred, material certified) and the current state is calculated from that sequence, the way a bank balance is calculated from transaction history rather than stored as an editable number.

This makes the audit trail the primary record, not a by-product. If information turns out to be wrong, the correction is written as a new event alongside the original, so the history shows both the error and its correction, exactly what an auditor needs.

Critically, this is enforced, not promised. The application has no code path that can alter or delete history, and an automated check in the build pipeline rejects any change that would introduce one. The build fails before a violation can ship. As built, the enforcement now runs a layer deeper than this document originally promised: the database itself refuses updates and deletes on the event record, independently of the application.

Tamper Evidence

Append-only code protects the record from the application. Tamper evidence extends that protection against someone with direct access to the database itself, in two layers.

Hash-chaining (from milestone M2; in code today). Every event carries a cryptographic fingerprint of the event before it, forming a chain. Change any historical event (even one character) and its fingerprint no longer matches the one embedded in the next: the chain visibly breaks from that point forward. Tampering is not made impossible; it is made detectable, which is what auditing requires.

Public anchoring (from milestone M3; in code today). At regular intervals the platform condenses the whole chain into a single fingerprint and has it timestamped by a free public authority under RFC 3161 (e.g. FreeTSA), an open, widely-used standard that is the digital equivalent of a notary's date stamp. That fingerprint is also mirrored to a public GitHub witness anyone can inspect. From then on, even REZET HUB itself could not silently rewrite its past: any alteration would contradict a fingerprint held outside the company. A qualified, contractually-backed authority plus write-once (WORM) storage is an optional enterprise upgrade, only if a customer requires it.

REZET HUB says tamper-evident, not tamper-proof: the promise is that any change leaves a visible trace. There is no blockchain and no cryptocurrency anywhere in the design: only anonymous fingerprints, never data, are ever published.

The record is a forward-only chain; the material is a loop

A circular economy is a loop: material is collected, moved, recycled, remade and bought, then comes round again as new feedstock, and a single organisation can occupy several points of that loop at once (a recycler that also manufactures; a generator that also buys recycled material). It is worth being exact about what loops and what does not, because that distinction is what keeps the proof sound.

The material loops; the chain of record does not. The provenance record is append-only and forward-only: every event carries the fingerprint of the event before it, so the record can only grow forward and can never bend back on itself. A looping record is not merely avoided, it is impossible (an earlier event cannot contain the fingerprint of a later one), and that impossibility is exactly what makes the chain verifiable.

The loop lives in the material graph, written as forward events. Each aggregate (a collection, a batch, a product) is its own forward chain; those chains are stitched together by mass-balance links as material moves and combines. When material re-enters the loop, becoming feedstock again, it is recorded as new events that reference the earlier ones, the way a version-control history (git) represents endless cycles of collaboration as a graph that only ever grows forward and never contains a cycle. The circular economy is a spiral through time: the same materials return as new instances, with later timestamps, never as a backward edge in the record.

Verification follows the chain, not the loop. To check any point, the record is walked forward from an independently anchored checkpoint (the public timestamp described above); altering any past event breaks every fingerprint after it, and the external anchor witnesses the whole. So the loop can close anywhere in the business (inside one organisation or across several) without ever weakening the guarantee, because the guarantee rides the forward chain of record, not the material's circular path. The proof spine connects the loop; it is never shaped as one.

Privacy Protection

A permanent record and the right to be forgotten sound incompatible. REZET HUB resolves the tension by never letting the two kinds of data mix.

Personal information is stored only in the identity vault, encrypted with a separate key for each person. Those keys live in a dedicated key store (a managed KMS/HSM), never in the database or its backups. The permanent provenance record never contains a name: people appear only as opaque tokens. When a person exercises their right to erasure, the platform destroys that person's encryption key (a technique called crypto-shredding). From that moment their personal data is unreadable everywhere, including in every backup, while the provenance record, which only ever held their token, remains complete and verifiable.

The result: audit history and privacy law stop competing. The record stays intact for the auditor; the person disappears for good.

Independent Verification

Every provenance system ultimately faces the same question: why should anyone believe the operator of the database? Most answer with policy: access controls, certifications, assurances. Those all reduce to "trust us."

REZET HUB is engineered so the answer does not depend on trusting REZET HUB. The append-only rule is enforced by automated checks in the build itself. The hash chain lets integrity be re-verified mathematically by anyone given the data. The externally timestamped fingerprints mean verification does not even require REZET HUB's cooperation. The same philosophy governs delivery: milestones are verified by automated acceptance gates and an independent reviewer, not the team's own word: a company whose product is verifiability is built to be verified.

Build Once, Expand Many Times

The platform is built once, on a material-agnostic core, and expands along two independent axes.

More materials: add a profile, not a platform. Stage 1 ships textiles (recycled clothing and bags). Every other stream (plastics, metals, e-waste, any recoverable material) is added as a profile: its field set, composition vocabulary and passport layout. The append-only core, the identity vault, the tamper-evidence and the passport machinery are untouched. A new material is a configuration, not an engineering project. As built, this is no longer only a design intention: the flexible field-schema engine and the first textile field profile exist in code today.

More reach: region-pinned writes, global reads. The authoritative record is written once and pinned to the region the law requires: one authoritative instance per country. The public passport is a separate read copy, a simple cached read view at pilot, and cached at the global edge as the audience grows (a later, traffic-driven step), so it answers a consumer anywhere in milliseconds; the authoritative record never sees that traffic. Reads scale horizontally with the audience; writes scale by region. Pilot → national → international is a deployment sequence, not a re-architecture.

Development Roadmap and Build Status

The foundation gives the build a head start, and as of this revision the head start is substantially larger than the original plan assumed. The per-context stores, the integration-event spine, the personal-data-quarantine kit and the reference slice were the assumed baseline; beyond that, the identity vault, the full custody chain, hash-chaining, mass-balance accounting and the external public anchor now exist in code and build cleanly (each traceable to a merged commit in the Build Progress Report). That, plus the 30 July end-to-end validation noted above, is the reason the window to a piloted v1 is 4–6 months, with the fundable proof point (a hash-chained public passport, formally accepted) landing at the end of M2, roughly 3 months in.

No milestone beyond M0 is claimed as accepted (as the Executive Summary notes): the remaining durations below are the validate-and-accept work plus the unbuilt scope.

M0 · Foundation — complete

• Objective: the event-sourced skeleton on which everything else is built.
• Delivered: the append-only stores, the security model, the automated build gates that enforce the architecture rules, the provider-agnostic AI seam, and one complete reference slice end to end.
• Acceptance: complete; the assumed baseline of this plan.

M1 · Identity + first passport + role-set onboarding — built; core validated running (30 Jul); acceptance pending · 2–4 weeks remaining

• Objective: stand up the identity vault and prove the whole pipeline in miniature on one real slice.
• Deliverables: organisation and actor registry; tokenised identity vault with per-person encryption; provisioned multi-organisation onboarding, where an organisation is stood up with its set of actor roles; the first provenance slice (textile intake by a waste generator); a thin public passport resolved from a QR code.
• Demonstration: scan a live passport for a batch recorded against a tokenised actor; replay reconstructs its full history.

M2 · Full provenance chain, the connected loop — substantially built; core validated running (30 Jul) · 6–9 weeks remaining

• Objective: extend the proven pattern across the whole lifecycle as one connected multi-role loop, and make the record self-verifying.
• Deliverables: logistics, processing and compliance contexts; event hash-chaining across the whole record; the cross-actor claim/accept handoff that joins each actor's leg across organisations; and the multi-role data-model completion, so one organisation can hold several roles on the same spine.
• Demonstration: one batch travels the entire loop, collected, transported, processed, certified, its legs contributed by their actors and joined across organisations by the claim/accept handoff, hash-chained end to end; corrupting a test copy visibly breaks the chain.

M3 · Verification, privacy, public anchor & per-role impact — early slices exist · 5–7 weeks remaining

• Objective: turn the trusted record into what auditors consume, add public independent verification, and attribute impact to each actor's role.
• Deliverables: point-in-time queries; verification-ready audit export; the erasure flow end to end; a free public timestamp anchor: the record's fingerprint timestamped by a public RFC-3161 authority (FreeTSA) and mirrored to a public GitHub witness (already in code); a cached public-passport read view; per-role impact, so each actor sees the impact attributed to its own leg of the loop (org-level rollups already in code).
• Demonstration: reconstruct a batch's state as of a past date; erase a person and show the passport still works; produce a verification export; timestamp a fingerprint and verify it independently against the public anchor.

M4 · Live textile pilot — not started · 2–3 weeks · in base

• Objective: a real textile product live in production, intake to passport, on material supplied by UTSC, the Australian launch operator.
• Deliverables: production deployment; the complete textile passport profile on a real product; the AI operator assistant wired to the provenance commands.
• Demonstration: scan the QR code on a physical product and read its true history.

Delivery Governance

A milestone is "done" only on objective signals, never a narration; think of it as a pre-flight checklist that will not let the aeroplane leave the gate. Each ends the same way:

Live demonstration. Every milestone ends in a live run of the exact scenario named in the roadmap, not a slide, not a recording. If it cannot run live, the milestone is not done.

Automated verification. The same gates run on every change: build, full test suite, security checks, and the architecture rules that enforce the append-only record and the personal-data quarantine. The gates are code, so they run identically every time and cannot be argued with.

Peer review. No change reaches the platform unreviewed: human-written or AI-assisted, it passes the same review and the same gates.

Independent review. At M2 and M3 the codebase and the delivered milestone are open to independent external technical review. The reviewer is never the builder.

Investor observation. Investors may nominate a technical observer at milestone demonstrations, with visibility of all change requests. Under a staged drawdown, each release of funds follows written milestone acceptance.

Written acceptance. A milestone completes only when REZET HUB accepts it in writing, after the live demonstration, green gates, review, and deployment to production-like staging. Nothing is accepted from a developer's laptop.

Performance Targets

Availability. 99.5% at pilot with a tested restore procedure, rising to a 99.9% design target at scale. These are engineering targets; the pilot is where the track record begins.

Performance. The public passport answers in under 200 milliseconds for 95% of cached reads (effectively instant to a consumer scanning a QR code), served from a globally cached layer that never strains the proof engine.

Security. Encryption in transit and at rest; role-based access control on every command; owner-scoped data access; a complete audit trail by construction; and tamper evidence hardened through hash-chaining (M2) and independent anchoring (M3).

Scalability. One codebase from pilot to global scale: reads scale at the edge, writes by region. See Build Once, Expand Many Times.

Engineering Investment

A piloted v1 (M1–M4) is ~A$153k all-in: the proof engine end to end plus the connected multi-role loop and a live textile pilot on a real batch, on a lean team (the founder-engineer as primary builder plus one supporting engineer), in roughly 4–6 months (the fundable proof point, a hash-chained public passport, lands earlier, at the end of M2). This is the same ask as v1.4, held unchanged: the build is substantially ahead, so rather than re-pricing that progress down to a cheaper, narrower build, the freed effort is redirected to the connected loop: the same agreed budget now buys the whole loop, not just the linear proof engine. The total includes infrastructure and development tooling, explicitly including the AI tooling seat that powers the delivery model (Claude Max, US$200/month per seat; one seat, the CTO), a free public anchor, a ~10% technical contingency, and a deliberately below-market CTO draw. Applications to the AWS and Cloudflare startup programmes are in progress; granted credits offset the cloud portion, and any surplus stays in contingency. Almost all of the money is product engineering; very little is overhead.

The full financials (the per-milestone budgets, the single-bridge vs staged-drawdown funding-release options) live in the Statement of Work v1.5, which is the single source of truth for the numbers. This is the summary; that document is the detail.

Team

The team's output is amplified by modern AI coding tools, with every change passing the same peer review and automated gates as any other: leverage under full control, not a delivery dependency. This is no longer a projection: the build record to date (the merged, independently gated work in the Build Progress Report) is what that delivery model produces. The timeline ranges are a conservative baseline that this can beat, not a target it must hit.

Duc remains CTO and technical founder and owner of the proof-engine architecture; REZET HUB owns the resulting platform, IP and codebase.

Technical Risks

Proof integrity

• Risk: a subtle flaw quietly breaks the guarantee the product is named for.
• Mitigation: every trust rule is an automated build gate: the build fails rather than shipping a violation; M3 adds independent anchoring, so tampering is detectable even without our cooperation.

Key person

• Risk: the proof-engine design and contributed foundation are the part-time CTO's.
• Mitigation: architectural invariants enforced in code, decision records maintained, peer review required, IP assigned to REZET HUB; the accepted state of every milestone is demonstrated, deployed to staging and reproducible, not resident in one person's head.

Regulatory

• Risk: data-residency and erasure obligations are interpreted differently by counsel.
• Mitigation: the legal surface is deliberately small (the identity vault only) and resolved with counsel in parallel; it does not block the build.

Pilot

• Risk: the first physical loop depends on a single launch operator (UTSC).
• Mitigation: the platform is operator-agnostic; an alternative operator is business-development lead time, not a code change.

Bridge underfunds v1

• Risk: the round comes in light and the build cannot reach demonstrable v1.
• Mitigation: work pauses cleanly at a completed, demonstrable milestone: a pause after M2 still yields a hash-chained provenance system, not a half-built one.

Planned Platform Evolution

(All dates indicative and funding-gated, sequenced after the asset that makes each valuable: a provenance record that can be trusted.)

Phase 1 · Trusted Provenance: this bridge (from commencement, ~4–6 months). Delivers the v1 proof engine (identity vault, full provenance chain, Digital Product Passport, tamper-evidence hardening), the connected multi-role loop, and the live textile pilot on a real batch. Consumer-scale read hardening and enterprise anchoring are funded by the Seed round.

Phase 2 · Marketplace & Billing: post-Seed (from H2 2027). Multi-sided billing and the recycled-goods marketplace, built on the proof engine that makes listed material trustworthy: the passport makes a claim credible, the marketplace makes it sellable.

Phase 3 · AI Classification: 2028. Photo-based material classification and input attestation (weighbridge and sensor feeds, laboratory references), tightening trust at the moment of first write.

Phase 4 · Carbon Intelligence: 2028–29. Carbon estimation and richer Scope 3 analytics computed from the provenance record, reported as clearly labelled estimates. (Provenance-backed impact factors and a GHG-Protocol Scope-3 export already exist in code today, ahead of this phase; Phase 4 deepens them into estimation and analytics.)

Conclusion

REZET HUB is not attempting to solve every problem in the circular economy in its first release. This investment funds one capability above all others: the creation of independently verifiable trust.

Every subsequent commercial opportunity (Digital Product Passports, compliance automation, sustainability reporting, and future marketplace services) depends on that trusted foundation. The seal is built first, because a passport is worthless if the record beneath it can be silently rewritten.

The architectural foundation already exists in the repository, with substantially more than the foundation now built and building cleanly (see the Build Progress Report). This investment converts it into a production-ready platform: tamper-evident by construction, verifiable by design, and governed by acceptance gates an investor can watch pass.

Appendix A · Technical Terminology

Appendix B · Architecture Decisions

1. Event sourcing over conventional CRUD: because the audit trail is the product, history must be the primary record, not a log bolted onto editable data. Applied only in the provenance contexts, where the log genuinely is the source of truth.
2. CQRS (separate read and write paths): consumer passport traffic must never strain or endanger the authoritative record, and each side scales independently.
3. Modular monolith over microservices: one deployable system at pilot scale, with bounded contexts and versioned integration seams, so later extraction is a deployment decision, not a rewrite.
4. Tamper-evident, not tamper-proof: auditors require detectability, not impossibility; hash-chaining plus independent RFC 3161 anchoring delivers exactly that without exotic infrastructure.
5. No blockchain, no cryptocurrency: tamper-evidence comes from standard, recognised RFC-3161 timestamping; only anonymous fingerprints are ever published, never data.
6. Personal data quarantined in one vault: GDPR-grade erasure and a permanent record coexist only if personal data never enters the permanent record at all.
7. Provider adapters for third-party services: a neutral port for AI, storage, email and payments keeps any future provider swap contained and the proof engine vendor-free.
8. Trust rules as build gates: every architectural invariant that carries the proof guarantee is enforced by automated checks that fail the build, so the guarantee cannot erode silently as the team grows.

Appendix C · Prototype to Production Evolution

The operational prototype proved the workflow and the demand: a public passport page, a chain-of-custody view and a document-seal concept, running on a conventional editable database. What it could not provide is the thing customers are actually buying: a record that provably was never altered. The prototype's seal hashes mutable rows, so it proves "this served document matches its hash," not "these facts were never changed": edit a row, re-serialise, re-seal, and the new hash is valid with no trace of the change.

The v1 build replaces the foundation rather than patching it (an append-only event-sourced core, the tokenised identity vault, hash-chained tamper evidence and independent anchoring) while preserving the prototype's proven product surfaces (the passport, the custody view, the impact reporting). The issue was the editable-record design, not the database: both the prototype and v1 run on PostgreSQL. Prototype historical data is deliberately not imported; v1 starts with a clean, verifiable record. This is an engineering gap to close, not a criticism of the prototype: the founders shipped proof v0, and v1 is the principled version that makes the proof defensible to an auditor and a regulator.