STATEMENT OF WORK (SOW)
v1 Proof Engine Platform Build — the spine that connects the circular loop
Version 1.5 · July 2026. This Statement of Work covers the ~A$153k v1 technical build: scope, milestones, governance and financials. It is read alongside three companion documents in the data room: the Technical Architecture overview (the system design, with diagrams), the Development Standards and Enforcement companion (the machine-enforced rules framework), and the Build Progress Report (commit-anchored evidence for every status claimed here). A detailed engineering Technical Scope of Work is available on request. The wider raise and market case sit in the investment proposal.
Status of confidence. The build is substantially ahead of this document's original starting assumption. On 30 July 2026 the core provenance path was validated running end to end on the local development stack: an operator recorded a waste collection, handed off custody, processed and sealed a product, and opened its public passport, with the environmental impact computed from the provenance chain itself and the tamper-evidence seal carrying an RFC-3161 anchor reference. Every underlying capability is traceable to a merged, independently gated commit (Build Progress Report; the repository is private, with read access granted to reviewers on request). What is not claimed: the platform is not deployed to a shared staging environment, no milestone beyond M0 has passed its formal acceptance gate, and nothing is in production. Timing and cost are base-case ranges, priced against the work that remains.
What changed from v1.4
Area
v1.4
v1.5
The ask
A$153k
A$153k, unchanged. The build is ahead of plan, so the same agreed budget now buys the connected loop on top of the proof engine (§A.9)
Timeline
5–6 months
4–6 months; fundable proof point ~month 3
Build status
Foundation + one reference slice
M1 built, M2 substantially built; the core chain validated running end to end (locally, 30 Jul 2026)
Scope
Proof engine only: identity vault, provenance chain, public passport, tamper-evidence (the material's linear journey, collect → certify → passport)
Same proof engine, now completed and described as the connected multi-role loop: one spine; five actors (generator, logistics, recycler, manufacturer, buyer); organisations may hold several roles; each actor sees its own impact, at the same A$153k ask. The marketplace stays parked (§A.5)
Team
CTO A$6k/mo + contractor + optional second developer
Founder-engineer (Duc) as primary builder + one supporting engineer, below-market founder draw
New in this version
—
Stage-1 users and workflows (§A.4) · the connected-loop description (§A.3) · Delivery Due Diligence (§A.12) · companion documents (Architecture, Development Standards, Progress Report)
The point of the bridge is unchanged: to harden a validated technical core into independently verifiable, piloted proof, not to claim that production-grade tamper-evidence already exists today. The connected loop is folded into that same build at the same ask (§A.9).
A.1 · Purpose
This Statement of Work defines the objectives, scope, deliverables, schedule, governance, acceptance criteria and financials for the v1 build of the REZET HUB platform, funded by the bridge round. Market sizing, customer evidence and the terms of the raise are set out in the accompanying investment proposal; this document is the engineering half of that story, written to be read without an engineering degree yet precise enough to survive technical due diligence.
REZET HUB is the proof layer for the circular-materials economy. It records what happens to recovered materials as they are collected, moved, processed and certified, and turns that record into tamper-evident proof: impact reports, verification-ready exports, and a consumer Digital Product Passport reached by scanning a QR code. The product is the audit trail itself. The simplest mental model is a black-box flight recorder for recycled materials: every step is written down as it happens, in a form that cannot be quietly rewritten afterwards.
The proof layer is also the spine that connects the loop. A circular economy is a loop of actors: a waste generator's material becomes a recycler's feedstock, becomes a manufacturer's product, becomes a buyer's sustainable input, and the impact of each decision travels with it. Those actors are otherwise disconnected, working in spreadsheets and email (exactly how REZET HUB's launch partners operate today). REZET HUB connects them by making the provenance-and-impact record the shared spine every actor writes to and reads from. A single organisation can occupy several of these roles at once (a recycler that also manufactures and sells is routine), so the platform treats an organisation's set of roles as first-class and attributes impact per role.
Commercial context. The v1 proof engine is not a standalone engineering project. It underpins REZET HUB's platform business model: waste-generator subscriptions, operator access, routed material-movement fees, proof packs, per-unit passports and B2G licences. The build creates the technical proof layer those revenue streams require in order to be trusted, priced and scaled.
This Statement of Work covers the proof engine, the connected loop that rides on it, and the technical delivery only. It does not cover operator onboarding, sales, marketing, legal, workspace, company setup or physical operating-loop execution, each of which sits in a separate line of the bridge budget, outside this document. The materials marketplace (actors discovering and transacting with one another) is a sequenced later layer, out of scope in §A.5.
The v1 build turns a working proof-of-concept into a verification-ready proof engine that connects the loop's actors: the REZET domain, the identity vault, the provenance chain, the public passport and the connective impact spine, on an event-sourced foundation that already exists as a working skeleton, and, as of this revision, substantially more than a skeleton (Section A.6). Stage 1 goes to market with textiles (recycled clothing and bags) on a core built to extend to any material without a rebuild. Full tamper-evidence is the primary deliverable of this build, not a capability REZET HUB claims to have in production today: the bridge hardens the foundation into independently verifiable proof through hash-chaining from M2 and external anchoring in M3.
A.2 · Project Objectives and Commercial Value
Objective
Why it matters to an investor
A tamper-evident proof engine (append-only at foundation level; hardened through hash-chaining in M2 and independent anchoring in M3)
The trust asset itself. It gives auditors, regulators and brands a reviewable evidence base.
A connected loop on one spine (generator, logistics, recycler, manufacturer, buyer, each contributing their leg to one provenance-and-impact record)
Turns a set of disconnected operators into a coordinated loop without asking them to abandon how they work. The trusted record is the moat REZET HUB has; the network it connects is the moat it lets the company build: each actor writing to one verifiable spine makes the platform harder to leave and harder to copy.
Multi-role organisations, with per-role impact
Real operators wear several hats. The platform treats an organisation's role set as first-class and shows each role its own impact, so "see the impact of your decisions" holds for every actor.
A consumer Digital Product Passport, EU DPP-aligned
The visible, scannable product, positioned ahead of phased EU Digital Product Passport requirements.
Erasure and immutability together
A person's data can be deleted on request while the non-personal provenance record stays intact. The privacy-versus-proof tension is addressed by design.
Textile market entry on a reusable core
A first vertical on a platform that extends to other materials without re-architecture.
One codebase from pilot to scale
The lean build and the scale build are the same asset maturing; there is no future rewrite priced in. The loop and, later, the marketplace extend this same spine along the versioned event seams already built, not a second system.
Reliability and speed by design
Engineered toward high availability and a fast public passport (p95 < 200 ms cached at v1), with the measurable targets in Section A.3, so the pilot behaves like a product rather than a prototype.
A.3 · Solution Overview (High-Level Architecture)
A batch's life runs as a single spine across six bounded components. Each component owns its own records and passes a small, versioned event onward as custody changes hands. These components serve the loop's five material-flow actors (generator, logistics, recycler, manufacturer, buyer), and the spine is what connects them.
Architecture flow: the identity vault issues opaque tokens. Batch events then move through Generator, Logistics, Recycler / Processing, Compliance and Passport Assembly. The public passport is served from a cached read layer and carries no personal data.
The loop, described. The material moves through the loop as one continuous spine: a generator records waste at origin; a logistics operator records custody as it moves; a recycler allocates it to batches and processes it; a manufacturer composes and seals finished products (often the same organisation as the recycler); a buyer receives the product and reads its proven impact. Each actor contributes only its own leg, under its own tenant, and hands the baton on as a versioned integration event carrying the running proof tip. The impact layer folds every leg into the environmental figures and attributes them per actor, so each participant sees the impact of what it did. This is one spine, not five integrations. Two forms of the loop are in scope for v1: a single organisation holding several roles (the intra-organisation loop, which the built spine already supports because all legs share one tenant), and separate organisations connected across a handoff (the cross-organisation loop), where a lightweight claim/accept handoff transfers write authority for the next leg to the receiving actor. That handoff is the completing work of M2 (Section A.6); the spine mechanism it rides on is already built.
One forward-only record, a looping material: keep the two separate. The material loops: it returns as recycled feedstock, and one organisation can stand at several points of that loop at once. The record of it does not. The provenance chain is append-only and forward-only, each event cryptographically bound to the one before it, so it can only ever grow, never bend back on itself. When material re-enters the loop, that is written as new events referencing the earlier ones, the way a version-control history captures endless cycles of work while only ever moving forward. So the loop lives in the material; the chain of record stays a straight, verifiable line, and any point on it can be checked, because altering any past event breaks every fingerprint after it. The spine connects the loop; it is never shaped as one.
Four properties make the record trustworthy. Each is a real mechanism in the build:
Property
In plain terms
Append-only record
Facts are written once and never edited or deleted. The application has no code path that can alter history, and an automated check blocks any release that would introduce one.
Tamper-evidence
Append-only records prevent tampering through the application. Hash-chaining and public anchoring extend detectability to direct database-level tampering. From M2, each event is cryptographically linked to the one before it, so altering one event breaks the downstream chain. From M3, periodic fingerprints of the record are timestamped by a free public authority using the recognised RFC-3161 standard (e.g. FreeTSA), optionally mirrored to a public git record anyone can browse, so even database-level tampering becomes independently detectable, at effectively no cost. REZET HUB says tamper-evident, not tamper-proof: the promise is audit detectability, not metaphysical impossibility. Only fingerprints are ever published, never personal or commercial data; a qualified, contractually-backed timestamp / write-once tier remains an optional later upgrade for customers who require one.
Privacy with erasure
Provenance records carry only anonymous tokens, never names. Personal data lives in one separate vault, encrypted per person; erasing a person destroys their key, like emptying a cloakroom booth of names while every coat stays on its hook. Keys live in a dedicated key store, managed KMS / HSM, not in the database or its backups. Destroying a key renders that person's data unreadable across current records and prior backups, without rewriting the provenance log.
Reads scale separately (CQRS)
The public passport is served from a fast, globally cached read layer, independent of the authoritative record, so consumer traffic never strains the proof engine.
Connecting the loop without weakening isolation. The same discipline that keeps one organisation's data private (owner-scoped records, tenant isolation) is what makes cross-actor handoff safe: authority to write the next leg is transferred explicitly through the claim/accept event, never inferred, so a legitimate handoff between organisations is distinguishable from an attempt to write another organisation's record. The connective spine is built on top of the isolation, not by relaxing it.
Two design choices keep future options open. First, the platform starts as a modular monolith: one deployable system now, with bounded contexts that can later be extracted into independent services along versioned integration-event seams. Second, third-party dependencies such as AI, storage, email and payments sit behind provider adapters. This is not claimed as a moat; it is engineering hygiene that keeps future provider swaps contained.
This build proves a record was never altered after it was written, and connects the loop's actors around that record. Proving the first entry was true (that a bale really is 40 kg of the stated material) is the sequenced next layer, via weighbridge and sensor feeds, laboratory references and photo classification. The seal is built first, because a passport is worthless if the record beneath it can be silently rewritten.
Environments and service levels. The platform runs as three isolated environments (test, staging and production) from day one. Consumer reads scale through global edge caching; writes scale vertically first and then split along the component seams already built into the architecture. Physical multi-region deployment is a sequenced later step, not a rewrite. The build is engineered toward the following service levels:
Dimension
v1 pilot
At scale (design target)
Availability
At least 99.5%, with a tested restore
99.9%
Passport read speed
Under 200 ms for 95% of cached reads
Under 200 ms system-wide
Durability
Daily backups, restore rehearsed
Continuous replication
Access and privacy
Role-based access, encryption at rest and in transit, owner-scoped data
Plus independent tamper-evidence anchoring
These are engineering targets; the pilot is where the track record begins.
A.4 · Scope of Work (v1) — the Stage 1 Definition
The v1 build delivers:
• The event-sourced proof engine: the append-only provenance core recording each batch from collection to documented outcome.
• The connected loop on that spine: the generator, logistics, recycler, manufacturer and buyer legs, each contributed by its own actor, joined by the cross-actor claim/accept handoff so a batch's chain can span separate organisations as well as one multi-role organisation.
• Multi-role organisations: an organisation is provisioned with a set of actor roles, gets the merged workspace for those roles, and sees impact attributed per role.
• The tokenised identity vault, keeping all personal data separate, encrypted and erasable.
• The public Digital Product Passport, resolved from a QR code and carrying no personal data by construction.
• Reporting and verification-ready exports, including point-in-time state reconstruction, and per-actor impact reporting across the loop.
• Tamper-evidence hardening: hash-chaining from M2; a free public timestamp anchor from M3 (a public RFC-3161 authority such as FreeTSA, independently verifiable, ~$0).
• A provider-agnostic seam for the AI operator assistant.
• The first textile passport field profile.
Who uses it (Stage 1)
All business users are provisioned by their organisation: there is no public sign-up. The only anonymous surface is the public passport. An organisation may hold several of the roles below at once; it then sees the combined workspace and its impact broken down by role.
Stage-1 user
What they do in v1
Waste generator (a hotel, retailer or facility whose textiles enter the loop)
Records material at origin (the first immutable fact) and sees its own impact reports.
Logistics operator
Records pickup, transport and delivery: the custody handoffs between sites, carried on the spine.
Recycler / processor (the launch operator, UTSC)
The main workspace: receives material, allocates it to batches under mass-balance accounting, records sorting/processing and output composition, composes and seals finished products.
Manufacturer
Composes finished recycled products from batch outputs and seals their passports. Frequently the same organisation as the recycler, the multi-role case the loop is built for.
Compliance / certifier
Records declarations of conformity, test references and certifications against batches and products.
Buyer / brand
Read-only portal: the provenance and impact of the material and products they buy, with verification exports: the loop's closing view, where a buyer sees the proven recycled-content and impact behind what they sourced.
Consumer (public, no account)
Scans the product's QR code and reads its passport.
REZET HUB admin
Reference data (materials catalogue, facilities), organisation onboarding (including an organisation's role set and email-domain set), read-only support.
The Stage-1 workflow
One batch's journey around the loop, end to end. Every step writes permanent, tamper-evident evidence to the one spine, and each step below is a screen in the platform:
-
Intake: the generator records collected textile waste (weight, material, evidence photo): the chain's first immutable event.
-
Custody handoff: logistics records pickup and delivery to the recycler; custody transfers are part of the record. Where the next actor is a separate organisation, the receiving actor claims the batch and accepts the baton, taking write authority for its leg.
-
Allocation: the recycler allocates delivered material to processing batches; mass-balance accounting rejects allocating more kilograms than were received.
-
Processing: sorting and processing runs are recorded with their recovered-output composition.
-
Certification: conformity declarations and certifications are attested against the batch.
-
Product seal: a finished recycled product is composed from batch outputs and sealed (by the manufacturer); its Digital Product Passport is assembled from the record.
-
Public passport: a consumer scans the QR code and reads the product's true history; an auditor can verify the hash chain and the public anchor independently.
-
Reporting: impact reports, proof packs and verification-ready exports are generated from the same record for generators, buyers and auditors, with each actor's contribution attributed to it.
A.5 · Out of Scope
The following are excluded from v1 and sequenced deliberately after the proof engine and the connected loop that make them valuable:
• The materials marketplace: actors discovering, matching and transacting with one another (listings, offers, smart matching by recycled-content / impact / proximity / price, settlement and split payments). v1 connects the loop's actors around the proof spine; the marketplace that lets them find and trade with each other is the next layer, and by design a large one (a two-sided network with its own onboarding and settlement).
• Multi-sided billing.
• Richer AI features (photo classification, carbon estimation).
• Physical multi-region deployment.
• Import of the existing prototype's historical data.
• Legal and counsel work, go-to-market, and operating-loop execution costs, which sit in separate lines of the bridge budget.
A.6 · Deliverables and Milestones
The proof engine is built first, proven in miniature, then fanned out across the full loop. Every milestone ends in something an investor can watch working. As of this revision the build is substantially ahead of the original plan: the Status column states where each milestone stands, and the accompanying Build Progress Report traces every status to merged, independently gated commits. No milestone beyond M0 is claimed as accepted (acceptance requires the live staging demonstration and independent review of Section A.8); pricing in Section A.9 covers exactly that remaining validate-and-accept work plus the unbuilt scope. The connected loop is folded into the existing milestones, completing the spine rather than adding a stage (§A.9).
Milestone
What you can see when it is done
Status (30 July 2026)
Remaining duration
Depends on
M0 · Foundation
The event-store skeleton, security model and one working end-to-end reference slice.
Complete
—
None
M1 · Identity + passport + multi-role onboarding
An organisation provisioned with its set of actor roles; scan a live passport for one batch recorded against a tokenised actor; replay reconstructs its full history.
Built; core validated running (30 Jul); acceptance pending. Remaining: provisioned multi-organisation onboarding (with role sets), staging deployment, acceptance
2–4 weeks
M0
M2 · Full provenance chain — the connected loop
One batch travels the entire loop, collect to certify, append-only and hash-chained end to end; the legs are contributed by their actors and, across organisations, joined by the claim/accept handoff.
Substantially built (single-tenant chain); core validated running (30 Jul). Remaining: the cross-actor claim/accept handoff and the multi-role data-model completion, on the built spine
6–9 weeks
M1
M3 · Verification, privacy, public anchor & per-role impact
State as of any date; erase a person and the passport still works; verification export; the record's fingerprint published to a free public log anyone can check independently; each actor sees the impact attributed to its role.
Early slices exist (public anchor already in code; org-level impact rollups built)
5–7 weeks
M2
M4 · Live textile pilot on the loop (in base)
A real textile product live, intake to scannable passport, on material supplied by the launch operator (UTSC): the fundable proof point, on real material, with the loop's actors connected.
Not started
2–3 weeks
M3
A.7 · Project Schedule
Phase
Timing
Outcome
M1
Months 0–1
The validated core deployed to staging, provisioned onboarding with role sets built, and the first milestone formally accepted
M2
Months 1–3
Full loop of custody, hash-chained and accepted, actors connected across the handoff: the fundable proof point
M3
Months 3–4½
Verification-ready, publicly anchored, per-role impact across the loop
M4
Months 4½–6
Live textile pilot in production, on a real batch
Total duration: approximately 4 to 6 months to a piloted v1 with the founder-engineer building full-time plus one supporting engineer. The built-ahead proof engine is faster than v1.4 assumed, and that saved effort is redirected to the connected loop (the cross-actor handoff, multi-role completion and per-role impact), so the window holds near v1.4's rather than shortening. The fundable proof point (a live passport on a hash-chained record, actors connected across the loop, formally accepted) lands at the end of M2, roughly 3 months in.
A.8 · Governance and Acceptance Criteria
A milestone is complete only when all of the following hold:
• It is demonstrated live to the founders, running the exact scenario named in Section A.6.
• All automated gates pass: build, tests, security checks, and the architecture rules that enforce the append-only record and the personal-data quarantine, run identically every time.
• The work is peer-reviewed, and at M2 and M3 open to independent external review.
• It is deployed to a production-like staging environment, never signed off from a developer's laptop.
• An independent reviewer (not the builder), jointly appointed with the investor and paid from a neutral governance line (not the engineering budget), confirms the milestone against the objective signals (green gates + the live scenario run); at M2 and M3 this is an independent external review.
• REZET HUB accepts the milestone in writing on that independent confirmation, countersigned by the investor (or their nominated observer) before the next tranche releases.
Investor-side verification. An investor-nominated technical observer is welcome at every milestone demonstration, with the right to an independent technical review at M2 and M3. Because the founder-engineer is the primary builder (Section A.11), acceptance is never the builder's alone: funds release on the countersigned acceptance above, under the staged drawdown of Section A.10.
Change management. Any change of scope is submitted as a written change request with its business justification, cost estimate and schedule impact, and is approved by the founders before being incorporated into the plan. The investor observer has visibility of all change requests.
A.9 · Financials and Use of Funds
The ask, in 60 seconds
A$153k buys a demonstrable and piloted v1 in ~4–6 months: the proof engine end to end (identity vault, full provenance chain, public passport)* plus the connected multi-role loop*, the loop's actors connected across it,* publicly anchored and privacy-erasable, proven on one real textile batch*. Milestone-gated delivery: every milestone ends in a live demonstration*
This is the same ask as v1.4 (A$153k), held unchanged, and it now delivers more (below). The pilot is where the platform stops being a cost line: it produces the first reference customer and validates Proof Pack economics under the financial model's subscription tiers.
Why the connected loop fits inside the unchanged ask. v1.4 was priced at A$153k against a spine still to be built. That spine is now built and validated running (Section A.6), so the remaining proof-engine work is worth less than the full A$153k. Rather than return that saving as a cheaper, narrower build, it funds the connected loop: the cross-actor claim/accept handoff, the multi-role data-model completion and per-role impact ride on the existing provenance events (the "loop" is in large part the description the earlier plan lacked), so the loop is absorbed into the existing milestones (M2 and M3) at the same, originally-agreed A$153k. The investor receives more delivered scope (a connected multi-role loop, not just a linear chain) for the number already agreed.
This is the technical build only: the Product-&-Engineering slice of the broader bridge; legal, go-to-market, the marketplace, the operating loop and workspace are separate lines outside this document. All figures are AUD, ex-GST.
Where the A$153k goes
Line
Amount
Senior engineering — founder-engineer (Duc) as primary builder + one supporting engineer (M1–M4, incl. the connected loop)
~A$107k
CTO founder draw (below-market, part-time founder role)
~A$24k
Infrastructure + development tooling (incl. AI tooling seat)
~A$8k
Technical contingency + independent-review governance (~10%)
~A$14k
Total, all-in
A$153k
The infrastructure-and-tooling line is budgeted without credits and explicitly includes the AI development tooling that powers the delivery model: Claude Max at US$200/month per seat (one seat, the CTO, for the build window). Applications to the AWS and Cloudflare startup programmes are in progress; granted credits offset the cloud portion of this line, and any surplus stays in contingency.
Who the engineering line pays. The ~A$107k senior-engineering line funds the founder-engineer (Duc) as the primary builder plus one supporting engineer for redundancy, reflecting who has actually built the platform to date and letting the founder commit full-time rather than carve the build out of evenings. To keep the arrangement clean and investor-verifiable: the supporting engineer is a committed minimum of ~40% of this line (~A$40–45k), engaged before M1 acceptance. The founder draws the balance as an engineering wage at the same senior day-rate (A$800–1,200/day), only for delivered days on milestones that pass acceptance. The founder's total cash from the raise (engineering wage + the A$24k founder draw) is capped in the founder-terms agreement (~A$88k), with the split reported to the investor observer at each drawdown. The total and the per-milestone budgets are unchanged; this only makes explicit who fills the line and under what discipline.
The CTO draw is deliberately below market (A$4,000/month, part-time founder role); the founder's real stake is the contributed platform IP and unpaid time. The founders also contribute A$40k from their own income (A$15k already paid, A$2.5k/month from August 2026) alongside a CTO draw set below the SoW's own day-rate floor; none of that contribution is drawn from the raise. Public anchoring uses a free public transparency log rather than paid infrastructure. (Provider-by-provider infrastructure cost detail across scale tiers is in the running-cost projection, held in the data room.)
What each milestone buys
Each milestone is priced at its share of the held A$153k: the proof-engine portion re-based for the work already in code (plus an allowance for validating, hardening and accepting it), with the freed effort redirected to the connected-loop work (the cross-actor handoff and multi-role completion in M2, per-role impact in M3).
Milestone
Remaining duration
Buys
Budget
M1 · Identity + first slice + passport + role-set onboarding
2–4 wks
Validation, hardening and acceptance of the built identity vault + live passport; multi-role provisioning
~A$22–30k
M2 · Full provenance chain + hash-chaining + connected loop
6–9 wks
Completion of the custody chain, hash-chained, actors joined across the claim/accept handoff: the fundable proof point
~A$52–68k
M3 · Verification, privacy, anchor & per-role impact
5–7 wks
Auditor-ready exports, erasure, point-in-time state, public independent verification, per-role impact
~A$28–40k
M4 · Live textile pilot
2–3 wks
A real product, on real material, intake → scannable passport, on the connected loop
~A$15–22k
Delivery + ~10% contingency
~4–6 mo
A$153k all-in
The band on each milestone is the senior day-rate spread (A$800–1,200/day) on the founder-engineer + supporting-engineer plan (the same rate applies to whoever delivers the day).
Included and excluded
Included in this SoW
Excluded (elsewhere in the bridge, or later)
Senior engineering · CTO draw · dev tooling
Legal & accounting · GST (figures ex-GST)
Pilot infrastructure: test, staging, production
Future hiring · marketing & go-to-market
Basic cloud services · the free public anchor
The materials marketplace & settlement · read/edge-scaling & enterprise anchoring (Seed) · prototype-to-v1 data import
A.10 · Funding Release Options
Because the founder-engineer is the primary builder (Section A.11), staged drawdown is the default structure for this build:
• Staged drawdown (default): funds released against investor-countersigned written milestone acceptance (Section A.8); the strongest de-risking use of the acceptance gates.
• Single bridge (by agreement): drawn up front, if the investor prefers; the per-milestone budget is the spend schedule and milestone acceptance (Section A.8) is the governance.
Milestone
Budget
Spend window / release point
M1
~A$22–30k
Months 0–1 · on commencement
M2
~A$52–68k
Months 1–3 · after M1 acceptance
M3
~A$28–40k
Months 3–4½ · after M2 acceptance
M4 · live pilot
~A$15–22k
Months 4½–6 · after M3 acceptance
A.11 · Team, Roles and Responsibilities
Who
Role
Basis
Duc Nguyen — founder-engineer / CTO
Primary builder of the platform, plus architecture, proof-engine design, the AI seam, technical leadership and milestone review.
Below-market founder draw (A$4k/mo) + an engineering wage for delivered accepted days (senior day rate), capped per the founder terms
One supporting engineer (AU timezone)
Redundancy and throughput: builds offload-able slices against the reference template, reviews, and is a second person in the codebase.
AU senior day rate
External counsel (as needed)
Data-residency and erasure questions.
Outside this budget
Key-person reality: the proof-engine design and contributed foundation are the CTO's; the structural mitigation is set out in Section A.12. The delivery record to date (the volume of gated, independently verified work already merged) demonstrates that build throughput comes from the delivery system, not from one person's hours. Duc remains CTO / technical founder and owner of the proof-engine architecture; REZET HUB owns the resulting platform, IP and codebase.
A.12 · Delivery Due Diligence
This section answers the diligence questions a reviewer asks after reading the plan: when in calendar terms, with whom, in what order, and what happens if something goes wrong. Figures and milestone definitions are those of Sections A.6–A.10; this section adds no new scope.
Calendar schedule
Milestones are scheduled relative to commencement, because the start date depends on the funding close. Anchored to a worked commencement of 1 September 2026, the plan reads:
Milestone
Window (§A.7)
Calendar (commenced 1 Sep 2026)
Visible outcome
M1 · Identity + passport
Months 0–1
September 2026
Validated core on staging, provisioned onboarding with role sets, first milestone accepted
M2 · Full provenance chain + connected loop
Months 1–3
October – November 2026
Full loop of custody, hash-chained and accepted: the fundable proof point, ~end November 2026
M3 · Verification, privacy & public anchor
Months 3–4½
December 2026 – mid January 2027
Verification-ready, publicly anchored, per-role impact
M4 · Live textile pilot
Months 4½–6
Mid January – February 2027
A real textile batch live, intake to scannable passport
Shift every date by the difference between 1 September and the actual commencement date; the windows, not the calendar, are the commitment. The 4-month case completes around the end of December 2026; the 6-month case around the end of February 2027.
Where the build already stands. The schedule assumes the Status column of Section A.6 (statuses as of 30 July 2026). The schedule only ever moves on validated evidence, in the investor's favour: the timeline holds near v1.4's window (~4–6 months, §A.7), and formal pull-forward is claimed only after acceptance gates pass.
Resources
Who
Commitment
Basis
When engaged
Duc Nguyen (founder-engineer / CTO)
Full-time on the build once funded (part-time until then)
Below-market founder draw + engineering wage for delivered accepted days
Already engaged; primary builder, continuous M0–M4
Supporting engineer (AU timezone)
Full-time on the build
AU senior day rate, A$800–1,200/day
From commencement; redundancy + delivery share across M1–M4
External counsel (as needed)
Ad hoc
Outside this budget
Data-residency and erasure questions, M3
The build is led by the founder-engineer, with a supporting engineer carrying an offload-able share for redundancy and throughput; the per-milestone budget bands in Section A.9 are the same senior day-rate spread applied across the two. The plan's robustness comes from what makes the build independently continuable regardless of who holds the keyboard (the key-person mitigation below).
Sequencing and dependencies
The write-side spine is strictly sequential: each milestone consumes the previous one's accepted output, which is why the gates are meaningful:
M0 foundation → M1 identity + passport → M2 full chain + connected loop → M3 verification & anchor → M4 pilot.
Three tracks parallelise off the spine without gating it, sequenced within the founder-engineer + supporting-engineer plan:
• the operator capture app (camera-to-confirm data entry) alongside M2–M3;
• regulatory reference-data curation (EU DPP field sets, code-lists) alongside M2–M3;
• frontend and brand work (passport presentation, marketing site) at any point.
Commercial ↔ technical milestone map
Each technical gate unlocks a commercial motion; the two tracks are paced to meet:
Technical milestone
What it unlocks commercially
M1 · first live passport
A demonstrable artifact for design-partner and pilot conversations: something to put in a prospect's hands rather than a deck
M2 · hash-chained connected loop (fundable proof point)
The evidence base for Seed conversations; investor-observer demonstration; the technical-DD story becomes "verify it yourself", and the loop shows the network the platform coordinates
M3 · verification exports + public anchor
The auditor/brand conversation: independently checkable records, privacy-erasure answered, per-role impact. The compliance sales motion opens
M4 · live pilot on real UTSC material
The first case study and reference customer; validates Proof Pack economics on a real batch; the Seed raise is made on this
Pricing across these conversations is the financial model's (Core A$500 / Growth A$1,000 / Enterprise A$2,000 per month, plus Proof Pack revenue); the pilot's role is to validate delivery cost under those prices via the running-cost model.
Contingency and knowledge transfer
Budget contingency. A ~10% technical contingency (~A$14k) is carried inside the A$153k total, not on top of it. It is drawn only through the written change-request process in Section A.8, so the investor observer sees every draw and its justification.
Schedule contingency. Milestone windows are quoted as ranges; the 4–6-month total already spans the conservative end. Slippage beyond a window surfaces at the next milestone gate: under staged drawdown (Section A.10), funds for the following milestone simply do not release until the current one is accepted, which caps the investor's exposure to one milestone at a time.
Key-person risk and knowledge transfer. The risk is concentration on the founder-engineer: he is the primary builder and the proof-engine design is his. The mitigation is structural, not rhetorical. A supporting engineer is in the codebase throughout, plus:
• The architecture rules are enforced by the machine, not by memory: a change that violates the append-only record, the personal-data quarantine, or the access-controlled read path fails the build for any developer, present or future.
• Every significant decision is an immutable Architecture Decision Record in the repository, beside the code it governs.
• Every change is independently reviewed before merge, and every milestone is accepted by an independent reviewer against objective gates, so at each gate, the accepted state is demonstrated, deployed to staging, and reproducible, not resident in one person's head.
• IP is assigned to REZET HUB; the platform, codebase and records are company property.
The practical test a diligence reviewer should apply: could a competent senior .NET engineer, with no handover call, pick up the repository and continue safely? The enforced rules, decision records and reference implementation are designed to make the answer yes: being provably continuable is the same property the product itself sells.
A.13 · Risks and Mitigations
Risk
Exposure
Mitigation
A flaw quietly breaks the proof guarantee
High impact
Every trust rule is an automated build gate: the build fails rather than shipping a violation. M3 adds a free public anchor, so tampering is detectable even without REZET's cooperation.
Cross-actor handoff is genuinely new work on the built spine
Medium, carried in M2
The spine mechanism (versioned events, mass-balance edges, running proof tip) is built and validated; the handoff adds an explicit claim/accept transfer of write authority on top of it, not a new architecture. It is scoped inside M2's band and gated: M2 is not accepted until the connected loop runs end to end on staging. If it proves larger than budgeted, it surfaces at the M2 gate before M3 funds release.
Input truth ("garbage in")
Medium
After-write integrity is layer one (this raise). Input attestation via weighbridge and sensor feeds, laboratory references and photo classification is the sequenced next layer.
Key-person dependency on a part-time CTO
Residual, carried
Invariants enforced in code, decision records, independent review on every change, IP assigned to REZET HUB (Section A.12).
Data-residency and erasure obligations (legal)
Medium
A small, well-identified legal surface (the identity vault only); resolved with counsel and does not block the build.
Bridge underfunds v1
Medium
Work pauses cleanly at a completed, demonstrable milestone; a pause after M2 still yields a hash-chained provenance loop.
Pilot depends on a single launch operator (UTSC)
Medium
UTSC is lined up for the first physical loop; the platform is operator-agnostic, so an alternative operator is business-development lead time, not a code change.
The EU DPP specification shifts
Low
The passport schema is additive and versioned; profile changes extend the record rather than force a re-architecture.
AI-assisted code drifts from the architecture
Low
Every contribution, human or AI-assisted, passes the same peer review and automated build gates; the architecture rules fail the build on any violation.
A.14 · Assumptions
• A 4 to 6 month horizon from the start date.
• A lean team: the founder-engineer as primary builder plus one supporting engineer (the founder full-time once funded).
• The M0 foundation exists and is company-owned, and the further built work of Section A.6 is company-owned code awaiting acceptance; scope is held to Section A.4.
• The connected loop is completed on the existing spine (cross-actor handoff and multi-role completion), inside the unchanged A$153k ask (Section A.9).
• Australia-based delivery, in AUD, at pilot-scale volumes.
• Infrastructure budget and the v1 standards profile (GS1 Digital Link, PEF / ISO 14067) are partner-confirmed; the remaining open items (start date, pilot volume, and three legal questions for counsel) do not block starting the build.
A.15 · Sign-Off
The thesis is narrow and defensible: a provenance record that can be trusted, substantially built ahead of schedule, publicly and independently verifiable, and proven on a real batch inside this bridge. That trusted record, the spine connecting the loop's actors, is the asset the whole business is built to sell.
Role
Name
Signature
Date
CEO and Co-Founder, REZET HUB
Santiago Parsons
CTO and Technical Co-Founder
Duc Nguyen
Investor Representative
REZET HUB PTY LTD · STRICTLY PRIVATE AND CONFIDENTIAL · JULY 2026 · v1.5