REZET-HUB-Implementation-Schedule-v1.5.md

REZET HUB — IMPLEMENTATION SCHEDULE

Version 1.5 · 3 August 2026. This is the delivery plan for the v1 build: for every Stage-1 deliverable it states the exact functionality, where it stands today, the remaining work broken into individual tasks with an effort estimate each, who does it, the dependencies and order, start and finish dates under two funding scenarios, how completion is proven, the commercial milestone it unlocks, and the contingency if a person or resource is unavailable. It is written to be read and assessed without opening any code*. Where the technical substance already exists, it points to the companion documents: the Statement of Work v1.5 (SoW), the Technical Architecture v1.5 (TA), the Development Standards companion (DS) and the Technical Response (TR); where a detail was missing, it is added here.*

This is the investor edition of a two-edition pair: the external delivery plan. A separate Technical Annex (Engineering Edition)**, available on request, carries the same schedule with the code-level detail an incoming engineer would need; the two never diverge*: the dates, statuses, efforts, dependencies and budget figures are identical in both (Section 0, the Master Delivery Timeline §1.5, the four critical dates, the status table and the budget block); wording differs by audience, and any change to the numbers in one is mirrored in the other. All money is AUD, ex-GST, reconciled to the* approved and held A$153k budget (SoW §A.9).

0 · How to read this document

The two resource scenarios (used for every date and effort line):

Scenario A — Current Resource

Scenario B — Funded Base Case (A$153k)

Who builds

Duc (founder-engineer / CTO) only, strictly part-time (~2–3 focused build-days/week), running the AI-assisted delivery system that has produced the build to date

Duc full-time as founder-engineer and primary builder, + one supporting engineer (see Resourcing below). Duc also holds architecture, the security-critical build, review and acceptance (SoW §A.11–§A.12).

Funding

None drawn; founders' own contribution only (SoW §A.9)

A$153k bridge deployed per the milestone drawdown (SoW §A.10)

Effective throughput

Baseline: about 2.5 build-days a week land

About 5+ build-days a week land (~2× Scenario A): the founder-engineer ramps toward full-time and a supporting engineer is added. Deployment, the live pilot and legal work do not compress with money, so the multiple is held there, deliberately conservative given the added capacity.

Commencement

Continuous from now; Week 1 = week of 3 Aug 2026

On funding close; Week 1 = week of 1 Sep 2026 (worked anchor, SoW §A.12). Every Scenario-B calendar date shifts by the actual close date; the week numbers, not the calendar, are the commitment.

Resourcing (refines SoW §A.11). The senior-engineering budget (SoW §A.9, ~A$107k) funds the founder-engineer (Duc) as the primary builder plus one supporting engineer for redundancy, rather than a single external contractor. This reflects who has actually built the platform to date, and it is what allows the founder to commit fully: a real engineering wage from the raise, drawn from this existing line (not new money), is what lets the build stop being carved out of evenings. The supporting engineer keeps a concrete key-person answer: a second person in the codebase throughout (see §2.11). Budget totals are unchanged; only the picture of who fills the engineering line changes.

Effort is stated in working days: the labour content of a task, independent of who does it. Convert to calendar via the throughput above. At the standard senior rate of A$800–1,200/day (SoW §A.9), the total remaining effort converts back to the engineering budget.

Dates are given two ways for precision: a week number from commencement and the calendar date it lands on under each scenario's anchor above. The Master Delivery Timeline (§1.5) gathers every date in one place.

Status words: COMPLETE = built and exercised in the 30 July end-to-end run · SUBSTANTIALLY BUILT = core built, gaps named · PARTIAL = some parts built, real work remains · NOT STARTED.

One honesty note, carried from SoW §A.6: built is not the same as accepted. No milestone beyond the foundation has passed its formal acceptance gate (a live demonstration from a shared staging server, confirmed by an independent reviewer). The single biggest gap between "working in development" and "deliverable" is deploying to that staging server (deliverable D10 below). It gates the first external demo and every milestone sign-off.

SECTION 1 · Critical Target Milestones

Four events, defined unambiguously, each with the chain that must be true first, the week it lands, and the calendar date under both scenarios. Full working in §1.5.

Event — exact definition

Must be true first

Scenario A

Scenario B

Current State: what is live and functional today (audit below).

— (this is now)

3 Aug 2026

First External Demo: a private web address where a nominated observer drives the real platform end to end (record waste → move custody → seal a product → open its public passport), running on a shared server, not a laptop.

Staging live (D10) · passport on staging (D6) · one real second organisation provisioned (D2)

Week 14 — mid-Nov 2026

Week 4 — end-Sep 2026

First Tamper-Evident Passport on a Real Batch: a product passport sealed over a tamper-evident record built from a real UTSC textile batch, whose seal an outside reviewer can verify independently. The SoW fundable proof point, on real material.

Event 2 · full chain accepted (D3) · cross-organisation handoff (D4) · tamper-evidence accepted (D7) · a real UTSC batch dataset (commercial gate, below)

Week 30 — late-Feb / early-Mar 2027

Week 13 — end-Nov 2026

First Paid Enterprise Pilot: a real operator (UTSC as lead) running a real batch from intake to passport in production, under a paid Proof-Pack / subscription line. Commercial as well as technical: needs the pilot milestone accepted and a signed pilot.

Event 3 · verification, privacy & export accepted (D8) · production environment (D10) · signed pilot agreement (commercial gate, below)

Week 48 — mid-2027 (Jun–Jul)

Week 24 — Feb 2027

Two commercial gates, owned by the CEO (Santiago). These are not engineering tasks; they pace Events 3 and 4 and are shown so the technical and commercial tracks are visibly paced to meet (SoW §A.12):

Commercial gate

Owner

Gates

Target — Scenario A

Target — Scenario B

Real UTSC batch dataset ready to run through the platform

CEO (Santiago) + UTSC

Event 3

~Feb 2027

~mid-Nov 2026

Signed pilot agreement with the launch operator

CEO (Santiago)

Event 4

~Jun 2027

~Jan 2027

Target dates are the CEO's to confirm; they are penciled to align with the technical windows so neither track waits on the other.

1.1 · Current-State audit (Event 1, 3 August 2026)

Grounded in the platform as it stands today and validated by the 30 July 2026 end-to-end run, in which 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 record itself and the tamper-evidence seal carrying its public timestamp reference. Cross-reference: SoW §A.6.

Live and functional today (built and exercised end to end in development, on the builder's own machine, not yet a shared server):

• The tamper-evident record engine: every fact is written once and can never be quietly edited or deleted; an automated check blocks any change that would break that rule.

• The full material journey: record waste at origin → custody handoff → allocate to a processing batch → process and record outputs → certify → compose and seal a finished product. Every leg is captured.

• Tamper-evidence, three independent layers: each record is cryptographically linked to the one before it, so altering one breaks the chain; the database itself refuses edits to history; and a fingerprint of the record is timestamped by a free public authority and mirrored to a public log, so tampering can be detected by an outside party without REZET's help.

• Mass-balance accounting: you cannot allocate more kilograms out of a batch than went in; the system rejects it at source.

• The public Digital Product Passport: scannable, carries no personal data, redesigned as a branded proof document showing the chain-computed impact and the tamper-evidence seal.

• The impact engine: environmental figures computed from the record, pinned to the factors in force at the time; organisation-level impact reports; auditor-ready exports; a downloadable, independently checkable proof pack.

• The multi-role foundation: an organisation's set of roles is recognised; each custody step is stamped with the role that performed it; the workspace and permissions follow the roles the organisation holds.

• The textile profile: the first textile passport field set, plus an AI assistant that pre-fills a value from a photo for a human to confirm, and a mobile capture app for evidence in the field.

• Security: the known cross-organisation forgery and data-leakage paths on the command path are closed and independently reviewed; the final piece, scoping every signed-in user strictly to their own organisation, is the remaining onboarding step (D2).

• The operator app: screens for every step above, plus a read-only buyer impact portal, in English, Spanish and German.

• The infrastructure blueprint: a one-command tool to stand up cloud environments (AWS), with access control and monitoring wired in.

True today, stated plainly: it runs in development, not yet on a shared staging server; no milestone is formally accepted; organisation set-up is in an early single-operator form (real multi-organisation onboarding is the next step); and by the founder's call it is not yet shown externally.

1.5 · Master Delivery Timeline

Every deliverable and gate on one dependency-ordered timeline. Week numbers are the commitment; calendar dates follow each scenario's commencement anchor (§0). ▸ = a milestone/event; ◆ = a commercial gate (CEO-owned). Owners: Duc (CTO) · Support eng (the supporting engineer) · Duc + support eng = shared.

Deliverable / gate

Owner

Effort (days)

Depends on

Scenario A**: weeks (calendar)**

Scenario B**: weeks (calendar)**

D2 Identity + provisioned onboarding

Duc + support eng

16–22

W1–W12 (Aug–late Oct 2026)

W1–W4 (Sep 2026)

D10a Staging server live

Duc (CTO)

6–10

AWS credits

by W12 (late Oct 2026)

by W3 (mid-Sep 2026)

D6 Passport ready for demo*

— (already built)

available now

▸ Event 2 · First external demo

D2, D6, D10a

W14 (mid-Nov 2026)

W4 (end-Sep 2026)

D3 Full journey finished + verified

Duc + support eng

6–10

D1, D10a (to prove on staging)

W13–W18 (Nov–Dec 2026)

W5–W6 (early Oct 2026)

D7 Tamper-evidence hardening + anchor

Duc (CTO)

4–7

W19–W22 (Dec 2026–Jan 2027)

W7–W8 (mid–late Oct 2026)

D4 Cross-organisation handoff

Duc (CTO) + support eng

12–18

D2, D3

W19–W28 (Dec 2026–Feb 2027)

W6–W10 (Oct–early Nov 2026)

◆ Real UTSC batch dataset

CEO (Santiago)

—

commercial

target Feb 2027

target mid-Nov 2026

▸ Event 3 · Tamper-evident passport, real batch (fundable proof point)

Event 2, D3, D4, D7, UTSC dataset

W30 (late-Feb/Mar 2027)

W13 (end-Nov 2026)

D8 Verification, erasure & audit exports

Duc + support eng + counsel

14–21

D1, D3, D10a

W29–W40 (Mar–May 2027)

W14–W18 (Dec 2026–mid-Jan 2027)

D6 Passport speed at scale

Support eng

5–9

D3, D10a

W35–W40 (Apr–May 2027)

W15–W18 (Dec 2026–Jan 2027)

D5 Multi-role + per-role impact

Support eng

8–12

D3, D8's reporting layer

W38–W42 (Apr–May 2027)

W17–W19 (Jan 2027)

D9 Textile profile + AI assistant

Duc + support eng

4–8

D3 (non-gating, runs in parallel)

done by pilot (Jun 2027)

done by pilot (Jan–Feb 2027)

▸ M3 acceptance

D5, D6, D7, D8

May 2027

mid-Jan 2027

D10b Production environment

Duc (CTO)

4–6

D10a, M3 accepted

W41–W44 (May–Jun 2027)

W20–W21 (mid–late Jan 2027)

◆ Signed pilot agreement

CEO (Santiago)

—

commercial

target Jun 2027

target Jan 2027

▸ Event 4 · First paid enterprise pilot

Event 3, D8, D10b, signed pilot

W48 (mid-2027, Jun–Jul)

W24 (Feb 2027)

*D6: the passport itself is already built and demonstrable now; its only remaining work is the speed-at-scale layer, which lands in M3 (after D3), shown on its own row. So D6 is "ready for the demo" without waiting on D3, while its remaining engineering completes later; no ordering conflict.

**D5 depends only on the reporting layer inside D8*, which lands mid-D8; it then completes just after, which is why D5 sits after D8 on the timeline in both scenarios.*

Total remaining effort: 79–123 working days. At Scenario A's 2.5 days/week that is ~32–49 weeks (≈ 8–11 months from early August 2026); at Scenario B's 5 days/week, ~16–25 weeks (≈ 4–6 months from commencement), matching the SoW §A.6/§A.9 window. Off-critical-path tracks (D6 scaling, D9 profile, frontend) run in parallel and do not extend these totals.

SECTION 2 · Stage 1 Delivery Schedule

Every Stage-1 deliverable (SoW §A.4), each with its functionality, status, task-by-task remaining work with an effort estimate and owner, resources, dependencies, the timeline reference (dates live in §1.5), how completion is proven, the commercial milestone, and the contingency. Key-person and resource contingency common to all deliverables is stated once in §2.11 and only flagged per-deliverable where it differs. Throughout this section, commercial milestones trace to SoW §A.12 and contingency framing to SoW §A.13; a citation below always points to a different SoW section.

Status at a glance

Del

Deliverable

Milestone

Status

Remaining (days)

Cost share*

The tamper-evident record engine

COMPLETE

—

Identity vault + provisioned onboarding

PARTIAL

16–22

part of M1 ~A$22–30k

Full material journey, single organisation

SUBSTANTIALLY BUILT

6–10

part of M2 ~A$52–68k

Cross-organisation handoff

NOT STARTED

12–18

part of M2 ~A$52–68k

Multi-role organisations + per-role impact

M2/M3

PARTIAL

8–12

part of M3 ~A$28–40k

Public passport (+ speed at scale)

M1/M3

SUBSTANTIALLY BUILT

5–9

M1/M3

Tamper-evidence hardening + public anchor

M2/M3

SUBSTANTIALLY BUILT

4–7

part of M2

Verification, privacy-erasure & audit exports

PARTIAL

14–21

bulk of M3 ~A$28–40k

Textile profile + AI assistant

M2/M4

SUBSTANTIALLY BUILT

4–8

M2/M4

D10

Deployment, environments & acceptance

M1–M4

NOT STARTED

10–16

across M1–M4

Total

79–123

A$153k all-in

*Cost is banded by SoW milestone (M1–M4), not per deliverable, because that is how the budget is drawn down (SoW §A.9). A deliverable spanning two milestones is funded from both. The whole-of-programme reconciliation (days → dollars) is in the budget note at the end.

D1 · The tamper-evident record engine — COMPLETE · M0

• Functionality: the write-once record at the heart of the product; facts are recorded once and never edited or deleted, with the rule enforced automatically.

• Status: COMPLETE; exercised in the 30 July run.

• Remaining work: none for Stage 1.

• Effort: 0 days. Timeline: delivered (§1.5).

• Depends on: nothing; it is the foundation.

• How completion is proven: the automated quality gates (which include the rule blocking any edit to history) pass on every change, the SoW §A.8 bar for the foundation.

• Commercial milestone: none directly; it is the trust substrate everything else is built on.

• Contingency: company-owned IP; no third-party exposure. See §2.11 for key-person cover.

D2 · Identity vault + provisioned multi-role onboarding — PARTIAL · M1

• Functionality: all personal data in one separate, encrypted, erasable vault; an administrator provisions an organisation, its set of roles and its first admin; that admin adds users; sign-in is by secure link, with no public self-signup; a separate staff/support area.

• Status: PARTIAL. The vault and the administrator-provisions-organisation flow are built; onboarding is in an early single-operator form.

• Remaining work (task by task):

Task

Effort (days)

Owner

Scope every signed-in user strictly to their own organisation's data

3–4

Duc (CTO, security)

Make secure-link sign-in login-only (never creates an account) + login page

2–3

Support eng

Org-admin screens to add and manage users

3–4

Support eng

Staff / support area behind access control

2–3

Support eng

Corporate single-sign-on: letting a client's staff log in with their existing company account (e.g. Microsoft or Google)

6–8

Duc + support eng

Corporate single-sign-on is the heaviest item; if time is tight it follows shortly after the demo without blocking Event 2 (see Contingency).

• Resources: the existing access-control service; an identity provider for single-sign-on; the staging server (D10) to demonstrate a real second organisation.

• Depends on: D1. Blocks Event 2 and D5.

• Timeline: §1.5 — A: Weeks 1–12 (Aug–late Oct 2026). B: Weeks 1–4 (Sep 2026).

• How completion is proven: an admin provisions a second organisation with its roles; its admin invites a user; that user signs in and cannot self-register; that organisation sees only its own data, and a user in one organisation provably cannot read another's.

• Commercial milestone: unlocks onboarding real operators, the design-partner and pilot conversation (M1).

• Contingency: if single-sign-on runs long, secure-link login ships first and single-sign-on follows without blocking the demo.

D3 · Full material journey, single organisation — SUBSTANTIALLY BUILT · M2

• Functionality: one batch travels the whole loop within a single organisation (intake → custody → allocation → processing → certification → sealed product) as one tamper-evident record.

• Status: SUBSTANTIALLY BUILT; validated in the 30 July run for a single organisation.

• Remaining work (task by task):

Task

Effort (days)

Owner

Close the remaining validation and consistency checks on the recently added logistics and recycler steps

3–5

Duc + support eng

Add the cross-step checks and confirm the whole journey on the staging server

3–5

Duc + support eng

• Resources: development environment and the automated test suite; the staging server (D10) for the acceptance run.

• Depends on: D1; the staging server (D10a) to prove it (it is built earlier, but formally accepted only once staging is live; see Contingency).

• Timeline: §1.5 — A: Weeks 13–18 (Nov–Dec 2026). B: Weeks 5–6 (early Oct 2026).

• How completion is proven: the intake-to-passport journey runs on the staging server through the real system; over-allocation is rejected at source; the record stays continuous across a multi-step batch.

• Commercial milestone: the technical substance of the fundable proof point (with D4 and D7).

• Contingency: every leg is already built, so this is hardening; under Scenario A the build completes before staging is live, so acceptance follows staging by a short margin. Slippage surfaces at the M2 gate (§2.11).

D4 · Cross-organisation handoff — the loop between companies — NOT STARTED · M2

• Functionality: when the next step belongs to a different company, the receiving company formally claims the batch and takes over authority to add its part, the mechanism that turns a single-company journey into a loop connecting separate companies (SoW §A.3).

• Status: NOT STARTED as an explicit handover. The protective guard that stops one company writing into another's record exists; the claim-and-accept transfer of authority is unbuilt. The SoW names this as the most genuinely new remaining work (§A.13).

• Remaining work (task by task):

Task

Effort (days)

Owner

Design the claim-and-accept step that transfers write authority to the receiving company without weakening isolation

3–4

Duc (CTO, security-critical)

Build the request-and-confirm link flow between the two companies

3–4

Support eng

Build the "pending handoffs" view and screens

2–4

Support eng

Tests for a real two-company chain (including that an outsider cannot claim and a forged acceptance is refused)

4–6

Duc (CTO) + support eng

• Resources: two provisioned organisations on the staging server (needs D2 + D10) to test a real handoff.

• Depends on: D2 (a real second organisation), D3 (the journey it rides on). Gates Event 3.

• Timeline: §1.5 — A: Weeks 19–28 (Dec 2026–Feb 2027). B: Weeks 6–10 (Oct–early Nov 2026).

• How completion is proven: company A records intake and offers the batch; company B claims and accepts; from then B can add its part and A cannot; the record stays continuous across the handoff; an outsider's attempt to claim, and a forged acceptance, are both refused.

• Commercial milestone: completes the fundable proof point and shows the network the platform coordinates, the evidence base for Seed conversations (M2).

• Contingency: scoped inside M2 and gated; if larger, it surfaces at the M2 gate (§2.11). The single-company loop (D3) is a working fallback: a pause after D3 still yields a complete tamper-evident loop (SoW §A.13). The authority-transfer design is reserved to the CTO in both scenarios (see §2.11, the security-critical exception).

D5 · Multi-role organisations + per-role impact — PARTIAL · M2/M3

• Functionality: an organisation holds a set of roles, gets the combined workspace, and sees its impact broken down per role (a recycler that also manufactures sees each role's impact separately).

• Status: PARTIAL. The role-set model, per-step role stamping, role-driven workspace and organisation-level impact reports are built.

• Remaining work (task by task):

Task

Effort (days)

Owner

Break impact down per role (building on the organisation-level report that already exists)

3–5

Support eng

Reconcile what an operator self-reports against what is measured

3–4

Support eng

Permission and live-update refinements

2–3

Support eng

• Resources: development environment and the test suite.

• Depends on: D3 (the steps carry the role) and the reporting layer inside D8 (per-role impact is a new view over that layer).

• Timeline: §1.5 — A: Weeks 38–42 (Apr–May 2027). B: Weeks 17–19 (Jan 2027).

• How completion is proven: an organisation holding two roles sees two separate impact figures; a role it does not hold is absent from its workspace and its live feed; a self-reported claim is reconciled against the measured value.

• Commercial milestone: "see the impact of your decisions" holds for every actor, the per-role impact story at M3 (SoW §A.6).

• Contingency: falls back cleanly to the existing per-organisation report if it slips; not on the critical path to Event 3.

D6 · Public Digital Product Passport (+ speed at scale) — SUBSTANTIALLY BUILT · M1/M3

• Functionality: the QR-resolved public passport, carrying no personal data, served fast from a cached layer (target: loads in under a fifth of a second for virtually every visitor, SoW §A.3).

• Status: SUBSTANTIALLY BUILT; the passport and its branded redesign are built and exercised, and are ready to demonstrate now. The remaining work is only the speed-at-scale layer.

• Remaining work (task by task):

Task

Effort (days)

Owner

Serve the public passport from a fast global cache so it stays quick under heavy public traffic

3–5

Support eng

Measure and confirm the speed target on the staging server; a few display and live-update fixes in the operator app

2–4

Support eng

• Resources: the content-delivery cache (free tier); the staging server (D10) to measure speed.

• Depends on: for the demo, only D1 (the passport is already built); for the speed work, D3 and the staging server.

• Timeline: §1.5 — passport demo-ready now; scaling A: Weeks 35–40 (Apr–May 2027), B: Weeks 15–18 (Dec 2026–Jan 2027).

• How completion is proven: scan a live passport on the staging server; it contains no personal data; the cached load time meets the under-a-fifth-of-a-second target.

• Commercial milestone: a working passport a prospect can scan and inspect themselves (M1).

• Contingency: the passport already renders; the speed work is hardening and can follow the first demo without blocking it.

D7 · Tamper-evidence hardening + public anchor — SUBSTANTIALLY BUILT · M2/M3

• Functionality: the three-layer tamper-evidence (each record linked to the last, the database refusing edits, and a public timestamp anyone can check): audit detectability, not tamper-proofness (SoW §A.3).

• Status: SUBSTANTIALLY BUILT; all three layers exist, unusually early. The remaining work is the acceptance demonstrations and supporting tests.

• Remaining work (task by task):

Task

Effort (days)

Owner

Put the public timestamping on a regular schedule

1–2

Duc (CTO)

Build the "break a record and watch it get flagged" demonstration

2–3

Duc (CTO)

Complete the coverage and continuation tests

1–2

Support eng

• Resources: a free public timestamp authority and a free public log; no paid infrastructure (SoW §A.9).

• Depends on: D3. Gates Event 3.

• Timeline: §1.5 — A: Weeks 19–22 (Dec 2026–Jan 2027). B: Weeks 7–8 (mid–late Oct 2026); the public-timestamp piece is formally accepted at M3.

• How completion is proven: alter a stored record directly in the database: the verifier flags the break; the periodic fingerprint is publicly timestamped; an outside reviewer confirms it without REZET's help.

• Commercial milestone: the "verify it yourself" technical due-diligence story (M2); the auditor/brand conversation at M3.

• Contingency: the public anchor is free, so there is no cost exposure; a paid, qualified-timestamp tier is an optional later customer upgrade, not part of v1 (SoW §A.3).

D8 · Verification, privacy-erasure & audit exports — PARTIAL · M3

• Functionality: reconstruct the record's state as of any past date; erase a person on request by destroying the single digital key that unlocks their personal data, after which it can never be read while the passport and record stay intact; auditor-ready verification exports.

• Status: PARTIAL. The proof pack, the greenhouse-gas export and the client impact report are built.

• Remaining work (task by task):

Task

Effort (days)

Owner

Fix the evidence-bundle download (currently stalls); do first

1–2

Support eng

Build state-as-of-a-date reconstruction

4–6

Duc + support eng

Complete the erasure flow

4–6

Duc (CTO) + counsel

Harden the audit exports and add secure, signed download links

3–4

Support eng

Pin personal and compliance data to the required jurisdiction

2–3

Duc (CTO)

• Resources: a secure vault that holds the keys (a managed key store); external counsel (ad hoc, outside this budget) on data-residency and erasure (SoW §A.11).

• Depends on: D1, D3, and the staging server (D10). This is the bulk of M3. Its reporting layer is what D5 rides.

• Timeline: §1.5 — A: Weeks 29–40 (Mar–May 2027). B: Weeks 14–18 (Dec 2026–mid-Jan 2027).

• How completion is proven: reconstruct a batch's state as of a past date; erase a person: their data becomes unreadable while the passport still resolves and the record still verifies; a verification export opens in the independent checker and validates.

• Commercial milestone: opens the compliance sales motion: independently checkable records with the privacy question answered (M3).

• Contingency: erasure is a small, well-identified legal surface (the vault only), resolved with counsel and not a blocker (SoW §A.13); if counsel is briefly unavailable the technical work proceeds and only the erasure sign-off waits. The download fix is isolated.

D9 · Textile profile + AI operator assistant — SUBSTANTIALLY BUILT · M2/M4

• Functionality: the first textile passport field set (aligned to the EU Digital Product Passport, and extendable without rework), plus a provider-independent AI assistant that pre-fills a value from a photo for a human to confirm.

• Status: SUBSTANTIALLY BUILT; the field engine, textile field set, photo-assist and mobile capture app are built.

• Remaining work (task by task):

Task

Effort (days)

Owner

Fill the missing textile translations across all three languages

1–2

Support eng

Complete the care-label code-list

1–2

Support eng

Make the photo-assist available to the mobile capture app

1–2

Duc + support eng

Route the AI assistant's entries through the human approval and audit trail

1–2

Duc (CTO)

(Deepening the field set as the EU rules firm up is a parallel, non-blocking curation task, not counted above; SoW §A.12.)

• Resources: the AI provider seat (already active; SoW §A.9); EU DPP reference data (curation track).

• Depends on: D3 (fields attach to batch and product records). Non-blocking for the main journey; runs in parallel.

• Timeline: §1.5 — starts once D3 is under way and completes before the pilot: A by ~Jun 2027, B by ~Jan–Feb 2027.

• How completion is proven: a textile passport shows every field in all three languages with none missing; the app pre-fills a value from a photo and a human confirms it before it is recorded; the AI assistant's entries go through the same approval and audit trail as a human's.

• Commercial milestone: the textile market-entry profile, the vertical the pilot runs on (SoW §A.2).

• Contingency: the profile is additive and versioned, so EU rule changes extend it rather than force a rebuild (SoW §A.13); the AI provider is swappable.

D10 · Deployment, environments & milestone acceptance — NOT STARTED · M1–M4 (critical path)

• Functionality: three separate environments (development, staging, production); every milestone signed off from staging, never a laptop (SoW §A.8); production for the pilot. This is what turns "working in development" into "accepted and demonstrable"; it gates Events 2, 3 and 4.

• Status: NOT STARTED on real infrastructure. The blueprint and the one-command stand-up tool are built; nothing is deployed; the AWS startup-credits application is in progress.

• Remaining work (task by task):

Task

Effort (days)

Owner

Secure the cloud credits, then stand up the staging server behind access control (D10a)

2–3

Duc (CTO)

Add an automatic deploy pipeline

2–3

Support eng

Rehearse a restore-from-backup

1–2

Duc (CTO)

Run each milestone acceptance from staging with an independent reviewer (spread across M1–M4)

3–5

Duc (CTO) + independent reviewer

Stand up production for the pilot (D10b)

2–3

Duc (CTO)

• Resources: AWS startup credits (the external gate; application in progress), then cloud spend per the running-cost model; the existing access-control and monitoring services (free tiers to start); an independent reviewer for acceptance and the M2/M3 external review (see §2.11).

• Depends on: nothing technical, but credit approval is the external gate on the first external demo. Blocks Events 2, 3 and 4 and every milestone sign-off.

• Timeline: §1.5 — staging (D10a) A: by Week 12; B: by Week 3. Production (D10b) A: Weeks 41–44; B: Weeks 20–21.

• How completion is proven: the full journey runs on the staging server behind access control, deployed by the pipeline, and an independent reviewer confirms it against the automated gates, the SoW §A.8 bar. A restore-from-backup is rehearsed.

• Commercial milestone: staging is the first external demo (Event 2); production is the paid pilot (Event 4).

• Contingency: if the credits are delayed, staging stands up on a small paid cloud spend: under Scenario B, from the infrastructure line (SoW §A.9); under Scenario A, founders self-fund that small interim spend (consistent with the founders'-contribution basis of the current-resource path). The one-command tool makes stand-up and tear-down cheap and repeatable, capping idle spend.

2.11 · Key-person, resource & continuity contingency (applies to all deliverables)

The answer to "what happens if someone drops out", stated once:

• If the founder-engineer (Duc) is unavailable (Scenario A). Scenario A is 100% Duc with no funded help, so the build simply pauses at the last completed, demonstrable deliverable. This is the plainest statement of the current-resource risk, and the core reason the raise de-risks delivery (SoW §A.12): funding puts a second engineer in the codebase, so the plan no longer rests on one person's evenings.

• Founder-centrality, and how it is mitigated (Scenario B). With the founder-engineer as the primary builder, the risk is concentration on Duc. The mitigation is structural: (a) a supporting engineer works in the same codebase throughout, giving continuous redundancy, review and a warm second person who can carry on; (b) the architecture rules are enforced automatically, so any engineer's change that would break the trust guarantees fails the build; (c) written decision records and a worked reference example make the work continuable with no handover call; (d) the platform IP is assigned to REZET HUB; (e) staged drawdown exposes only the current milestone while cover is arranged. The plan makes Duc's work independently continuable rather than pretending he is replaceable at a keystroke (SoW §A.12). The delivery record to date (the volume of gated, independently verified work already merged) is the evidence that throughput comes from the delivery system rather than one person's raw hours.

• If the supporting engineer is unavailable (Scenario B). Duc carries the line as primary builder while a like-for-like replacement is onboarded against the same enforced rules; the loss is smaller than the reverse case, because architecture and the security-critical work already sit with Duc. The timeline does assume the supporting engineer is engaged at commencement, a hiring lead-time that is itself a Scenario-B start-up risk; this is why the first external demo (Week 4, funded) is planned with little slack, and why the funded dates move with the actual engagement date.

• The security-critical exception. The cross-organisation authority-transfer design (D4) and the erasure design (D8) are reserved to Duc (as architect) in both scenarios. These specific tasks key to one person; that is the residual key-person risk.

• The independent reviewer. Milestone acceptance (SoW §A.8) and the M2/M3 external review require a reviewer who is not the builder. This is a modest engagement (a competent senior engineer for a demo-and-check per milestone); it is named here as a required resource so it is not overlooked. Because the founder-engineer is the primary builder, the reviewer is jointly appointed with the investor and paid from a neutral governance line (funded from contingency, not the engineering budget), with milestone acceptance countersigned by the investor before the next tranche releases under staged drawdown (SoW §A.8, §A.10).

• Continuity, in one principle. The practical test (SoW §A.12): could a competent senior engineer pick up the work with no handover call? Items (b) and (c) above are designed so the answer is yes, the same "independently continuable" property the product itself sells. This is why the per-deliverable sections do not each restate a bespoke handover plan: continuity is a property of the whole delivery system rather than a per-task document.

SECTION 3 · Stages 2 & 3 — High-Level Roadmap

Sequenced after the Stage-1 proof engine and connected loop (SoW §A.5 keeps these out of v1). Each item gets its dependency, an approximate effort band, the resources it needs and a realistic window. These are roadmap items, not v1 commitments: indicative, for sequencing. ("Connection point already built in" below means the platform was designed with a place to plug each of these in without re-architecting.)

Capability

Depends on (Stage 1)

Approx. effort

Key resources

Realistic window (post-v1)

S2.1

Regulatory-intelligence sync: keep the EU Digital Product Passport field sets and code-lists current as the rules evolve

D9 (the connection point is already built in)

15–25 days + ongoing curation

A regulatory data source; curation time

Seed, months 1–3

S2.2

Material-recognition engine: photo/vision recognition of material type and condition, to tighten input truth (the "is the first entry true" question, SoW §A.3)

D9 (the AI connection point); D1 (a record to attach confidence to)

25–40 days

An AI vision provider (connection point in place); a labelled reference set

Seed, months 2–5

S2.3

Recommendation & scoring: recycled-content / impact scoring and routing suggestions

D5 (per-role impact); D8 (the reporting layer)

20–35 days

Data volume from live pilots; scoring design

Seed, months 3–6

S3.1

Third-party integrations: weighbridge and sensor feeds, lab references, logistics/ERP links (the input-attestation layer)

D4; D1; the standard way outside suppliers are plugged in

10–20 days per integration

Per-partner access; adapter build

Seed → Series A, rolling

S3.2

Materials marketplace: companies discover, match and transact (listings, offers, smart matching, settlement, split payments). Explicitly out of v1 (SoW §A.5): a two-sided network with its own onboarding and settlement

D2; D4; D5; the connected loop as its substrate

Large: a distinct build, phased

A payments provider (connection point exists); marketplace onboarding + settlement; a dedicated team

Series A, its own Statement of Work

Sequencing logic: input-truth (S2.1, S2.2) and scoring (S2.3) enrich the record that already exists and ride the connection points already built, so they extend v1 rather than replace it (SoW §A.2, "one codebase from pilot to scale"). Integrations (S3.1) are per-partner and can run in parallel. The marketplace (S3.2) is deliberately last: it is only valuable once there is a trusted record and a loop of companies already connected to it (SoW §A.5), and it is large enough to warrant its own plan and team.

Appendix · Where each requested item is answered, and the budget

The twelve items requested, and where each is answered:

Item

Primary source

This document

Exact functionality per deliverable

SoW §A.4

Section 2, each D#, "Functionality"

Present status (done / partial / not started)

Build Progress Report

Section 1.1 + Section 2 status columns

Remaining work, task by task

the live delivery tracker

Section 2, per-deliverable task tables

Who is responsible

SoW §A.11

Section 2 task tables, "Owner"; §1.5

Estimated effort per task (days)

new here

Section 2 task tables; §1.5; status-at-a-glance

Resources required

SoW §A.9, §A.11; Deployment Plan

Section 2, "Resources"; §2.11

Dependencies and order

SoW §A.12; TA

Section 2, "Depends on"; §1.5 timeline

Start and completion dates

SoW §A.7, §A.12

§1.5 Master Delivery Timeline: week + calendar, both scenarios

Acceptance test per deliverable

SoW §A.8

Section 2, "How completion is proven"

Commercial milestone enabled

SoW §A.12

Section 2, "Commercial milestone"; the two commercial gates in Section 1

Contingency if a resource is unavailable

SoW §A.12, §A.13

Section 2, "Contingency"; §2.11

Continuity if the builder is unavailable

SoW §A.12 (key-person)

§2.11

Budget reconciliation. Every figure here is the A$153k plan of SoW §A.9: Senior engineering ~A$107k · CTO draw ~A$24k · Infrastructure + tooling ~A$8k · ~10% contingency ~A$14k, banded by milestone as M1 ~A$22–30k · M2 ~A$52–68k · M3 ~A$28–40k · M4 ~A$15–22k.

Days-to-dollars check: the 79–123 remaining working days at the senior rate of A$800–1,200/day (SoW §A.9) come to roughly A$105k at the midpoint, matching the ~A$107k engineering line. Within that line, the supporting engineer is a committed ~40% (~A$40–45k), engaged before M1; the founder draws the balance as an engineering wage at the same A$800–1,200/day, only for delivered days on accepted milestones; and the founder's total cash from the raise (engineering wage + the A$24k draw) is capped at ~A$88k and reported to the investor at each drawdown (SoW §A.9). It does not change the total. The below-market CTO founder draw (A$24k = six months at A$4k/month) is separate and unchanged; infrastructure (A$8k) and ~10% contingency (A$14k) complete the A$153k. Effort and rate bands do not both hit their maximum together; if they trend high, the ~10% contingency absorbs the first part and, under staged drawdown, scope or schedule for the affected milestone is adjusted at its gate before further funds release (SoW §A.10): the budget is an all-in cap, not an open bill. Scenario A draws no bridge funds (founders' own contribution only); Scenario B deploys the A$153k per the SoW §A.10 drawdown.

REZET HUB PTY LTD · STRICTLY PRIVATE AND CONFIDENTIAL · 3 AUGUST 2026 · Implementation Schedule v1.5 (Investor Edition) · reconciles to the Technical Annex and to SoW/TA/DS/TR v1.5