Malcolm walkthrough demo — 2026-07-08 (transcript notes)

Source: meeting transcript, two deliveries by Nia (who did not attend; video view-only). First paste (2026-07-09 morning) covered 0:00–2:40 + 40:00–53:16. Second delivery (2026-07-09, full screenshot capture of the whole convo) filled the previously-missing 3:53–40:00 middle segment — see “Middle segment” section below. The meeting is now FULLY captured. Attendees: Malcolm, Hung, Vu, Binh, Nathan (Nguyen Bui); absent: Nia, Jamie.

Process / timeline (standup + closing)

Shannon approved the UX/UI; Jamie’s update suggestions merge on Thursday (2026-07-10).
Show-and-tell with business stakeholders during this week; Shannon also discussing with industry/business partners. Development expected to start early next week (~2026-07-13).
Feature freeze: “we’re not adding more features now, we’re tidying up the features that we’ve got.”
After Jamie merges the UIs: Binh + Nghia + Nathan go through the Lovable app in depth and “test the hell out of it” — fake customers, fake orders, fake scans — verifying data flows end-to-end (scan at one end → evidence pack at the other with scans attached) BEFORE the dashboards are exported for Nghia to integrate. Rationale (Malcolm): “if we’ve got the logic wrong here, it’s going to be harder for Nghia and Vu to unpick this at an API level.”
BE side (standup): Hung — discussing query patterns for the Monet platform to decide per-table DB indexes (more discussion today/tomorrow, then updating). Vu — DB optimization call + “updated some APIs for Nghia to integrate”.

Business logic extracted

1. Certificates — multiple certificates per transaction (NEW)

Shannon raised questions about how certificates work for connected sub-tiers, which Malcolm had not catered for. Change: people can now attach multiple certificates to transactions. Malcolm is still reviewing the certificate process logic. (He flagged this as “more for Jamie” = UI-side, but the data model implication — transaction:certificates = 1:N — matters for BE/monet.)

2. Fibre Programme role model (~40:00–43:00)

Within a fibre programme there are exactly these roles:

Fibre producers = the gins producing fibre. Each gin has a start and end date, a production weight/amount contributed to the programme, and which facilities are active. These values show/hide things across the various UIs.
Fibre programme participants = the retail brands (e.g. Target). A participant can see the programme and how much they have reserved.
Manufacturers = everyone else in the programme, unless they have the “programme owner” flag switched on. Adding a manufacturer to a programme is “the equivalent of binding someone to a FibreTrace ID”: the pigment is tied to the fibre programme (cotton type set, etc.), and these manufacturers can see and can scan that pigment (e.g. the GEC pigment).
Programme owner = separate role/flag (not a supply-chain tier). Programme details (what FibreTrace says about the programme — info, logo, images) are editable by the programme owner. Known bug in demo: CRUD functions missing on programme details, not editable.
Admin override / CMS: programme-owner data (logo, images, wording) is visible to Admin under programmes; Admin can override a wrong logo and switch wording on/off — “some Admin UI functions that we don’t have in the current system” (i.e. new vs canvas).
Data-quality note: Binh is being used to check the programme data has no duplicates.

3. Supply-chain tiers (Binh’s question, ~49:00–52:00)

Retailer = Tier 0; raw fibre producer = Tier 4 (“a fibre manufacturer is typically the raw fibre, tier 4”).
Tier 5 would be the farm, but FibreTrace does NOT go in at the farm — it enters at the gin (so Tier 4 = gin is the origin anchor).
Between: spinning mill, fabric manufacturer, cut-and-sew (Tiers 3/2/1). This is standard apparel-industry terminology.
Cross-check: matches the tier table already verified in Lovable source (docs/application-overview.md, SettingsCompany dropdown): 0=Brand, 1=Final manufacturer/CMT, 2=Fabrics & components, 3=Material processing/spinner, 4=Raw Fibre Producer.

4. THE fundamental architecture decision — hardcoded apparel model (~50:20–52:00)

Direct contrast with canvas, stated explicitly by Malcolm:

Canvas: could trace anything — flexible, but put heavy obligation on the customer (understand tiers, set up orders and processes themselves).
The new tool (Lovable dashboard): heavily modified to only work with FibreTrace’s view of the apparel industry. Apparel-only, FibreTrace-supply-chain-only. Hard-coded to the tiered model and the purchase-order model. “This technology cannot be reused to trace other things.”
Consequence the business accepted: does what is needed today, but “hard to modify for the future without recoding large portions of it”.
Auditing app (SAT) simplification that follows from this: no need to set up orders in advance — only type in the shipping data you have; if you don’t have it, you don’t.

5. Data Connections (~43:52–46:50) — mostly FUTURE, one live piece

Data-connection functionality was “tidied up” the day before the demo.
Future/illustrative (NOT built): integrations into external systems managed per-connection — example shown: an API key + choose what to sync. Named example: Retraced would sync purchase orders, claim IDs, etc. “All got to be decided. Just there for illustrative purposes.”
The live piece: sharing claims / evidence packs. Example: a claim has packs — trade compliance, sustainability, procurement. For the trade compliance pack there is a public URL showing basic claim information. The QR code goes on the preview pack the retail brand shares with customs & excise; scanning it opens that public page and confirms the basic data.
Webhook version also exists: JSON output confirming validity + confirmed metric tonnage + access to the public URLs of each specific item.
Unsettled logic (Malcolm’s own words): verifications already have share links / copy sessions (built first, ~20 iterations ago). Malcolm is “still figuring out whether sharing is part of a data connection or not” — the verification-sharing part should be IGNORED for now; focus on the new items below it. He plans to tidy this up this week/next week.

6. Chatbot (~43:14)

Widened chat widget; multi-language; runs on Chatbase; currently reading OLD data — needs retraining on the new UI once completed. Logos not right yet.

Middle segment (3:53–40:00) — captured 2026-07-09 from full screenshots

Process facts (3:53)

Malcolm will CLONE the current Lovable app so Jamie can start UI integration on the interface. Jamie back ~2026-07-09; merging his brand-dashboard variations hopefully by end of week. Extra brand personas in the switcher are Jamie’s UI-comparison copies — ignore, they get merged.
Jamie has an empty-tier persona specifically to design empty states for a company’s first sign-in.
Lovable = MVP generation tool “running on Claude in the background”; Malcolm also uses it to output files: Jira import files, test and training data.
The Admin chip = a mini back-end for settings. NOT replacing the FibreTrace platform backend — it only specs the admin features that differ from today. Some already exist as cron jobs; SDUs are new.
Nghia, Binh, Nathan will be asked to test the interface incl. creating accounts.

Scanner flow update (7:00–16:00) — THE key change

Scanner sign-in: needs a platform user account. App tries GPS → match to a company facility; if no match, user picks the company location manually.
NEW: inbound/outbound scans now collect SHIPPING INFORMATION — “we’re tracing product movement… the movement of the pigment to the gin, from the gin to the spinning mill”. The consistent thing across all product movements is some documentation (even internal): we don’t know what the product is, but we know it’s fibre, where it came from / who it’s going to, and a reference number (waybill).
Partnership prerequisite (hard rule): for an inbound you select the partner it came from — only companies you already have a partner relationship with. “You can’t do an inbound for someone that you don’t have a partnership with. So you have to add them onto the platform. I haven’t catered for any options where that’s not the case.”
Shipping-doc matching: enter waybill → system tries to MATCH against the counterparty’s outbound. No match → user can edit the shipping ID or “confirm and continue” (stays an unconfirmed process); admin can add shipping data later; self-reported fields stay editable later. Mistyped waybill → fuzzy suggestion: “couldn’t find that, but I have got a shipment from that partner with this number. Did you mean that?”
Shipping data is OPTIONAL. Unmatched/absent → unconfirmed. Purpose (Malcolm, 15:29): “We’re using this to create a chain of custody… This is to help us build an IMPLIED chain of custody.”
Outbound scan = same flow, just picking whether you are sender or recipient. Both inbound AND outbound are expected per hop (Vu’s question, 24:36): a fabric mill makes fabric for MANY customers — supply is one-to-many, not linear — so each party declares which partner they shipped to, letting the platform “separate out individual customer supply chains” from the shared production.
Mass balance, not item-level trace (Malcolm, 24:36): “it’s impossible to say this bale ended up in this t-shirt. That’s not what we’re doing. We’re proving the MOVEMENT of fibre… country of origin we can do… it’s more of a mass balance concept.”
Scan mechanics otherwise unchanged from SAT/UAT (“Nghia has mocked all of this up in UAT anyway”); confidence score changes with scan count (5-scan example); can add bale ID (buggy, to fix); submit → summary → lands in Verifications as inbound/outbound scan.

Supply Chain page + tier visibility rules (16:00–24:00)

Tier-0 dashboard shows the active tiers related to the brand within a FibreTrace programme, linked purely from shipping data on scans: “Acme Apparel Tier 1 has been sending stuff to Target within this programme → part of the supply chain. Acme Tier 2 sent stuff to Acme Apparel 1. Sundown is the fibre producer, Target the participant.” This fills the missing tiers WITHOUT the old system’s orders/audits — “a simpler way of doing something very similar”.
New Supply Chain area: dashboard = simple view; supply-chain page = detailed view (evidence depth, quality of companies, scan counts, facility counts). Known demo bug: dashboard tier-4 widget only showed Sundown while multiple tier-4 companies exist.
Privacy rule: if the related company IS a partner → show company name + location. If NOT a partner → NO company name / exact location, only city + country (Malcolm to double-check with Jamie). A tier with no scans renders as a gap. Suppliers with scans who are NOT partners may not appear at all (Malcolm flagged the logic needs checking).
Onboarding: empty-state dashboards show vertical onboarding steps. Malcolm will recommend to the CS team that customer onboarding includes: adding team members, adding partners, setting up scanners, registering the facility.

Programme owner persona (26:34)

New persona, “someone like Danny at FibreTrace” — sees producers/participants/production amounts, updates aspects of the programme. “A little mini CMS because they’re the ones that set the programme metrics — like David and Danny decide whether it’s an EU claim directory of compliant programs, not FibreTrace.” They manage wording + documentation + certificates associated with programmes in their portal, and those items end up on the evidence packs.

Claim process A→Z (27:00–38:00) — Malcolm’s own words

Retail brand’s goal is twofold: physical — scan fibre on arrival at their warehouse → “it’s actually got FibreTrace in it → it is the stuff I paid for” → country-of-origin proof; digital — generate an evidence pack / make a claim, typically with customs: “I’ve imported this from Vietnam, and it is what I say it is.”
Claim certificate: produced with FibreTrace’s help; “a claim certificate creates packs”. Claim summary = claim ID (system-generated), programme, weight of raw fibre, date. Procurement / sustainability / risk-and-compliance packs = same data, different views. (Risk pack pretty much done, Shannon getting an industry person to review; others in progress.)
Claim quantity = the FIBRE component only: importing 10 mt of fibre from Vietnam that may be blended (could be 20 t of t-shirts at 50-50 Good Earth cotton + polyester) → the claim is for the 10 mt of FibreTrace fibre, “because you claim for the different composite components — there are different tax rules for different parts of the shipment (finished goods, fibre, raw materials)”.
Claim trigger requires a Purchase Order: retailer creates PO (bulk import or manual — duplicate data from their retail planning system), gives it a number, associates the tier-1 partner, picks the (single) fibre programme, quantity 10 mt → creates a notification to the partner.
Partner (tier 1) gets “purchase order shared” notification → opens the PO → “pick the verifications that were done on these 10 metric tons” → links their factory scans (as many as they want) → can attach a certificate at this point (pick existing or add new) → link and notify the brand.
Retailer: “items ready to claim” → PO with linked scans → review → confirm the claim → confirmed → appears in claims list with the packs (sustainability, risk, …) showing who was involved, how many scans, which facilities contributed. “All this data needs testing on these evidence packs — this is the bit you guys are going to help with.”
Recap (Malcolm): “the output of this entire process is to create a claim document that’s used to evidence the importation of fibres” — retailer asks manufacturer “for this PO, what scans did you do?”, manufacturer attaches, retailer reviews + makes the claim, then generates/views/shares the claim certificate — downloads it and sends to customs & excise in the US, with a QR code they can scan to check.
Jamie’s new-UI additions on client POs: send reminder (nudge) to tier 1 who hasn’t linked verifications; escalate to CS — Malcolm: gate escalate so it’s only available AFTER a nudge.
Internal claim preview view: all retail/manufacturing tiers involved + all partner scans; tier ordering should be chronological (Jamie note); the wording text comes from the programme owner CMS and is imported into the summary sheet; risk-pack preview gets a web-printable version → export PDF or share.

Other personas (38:33)

FibreTrace producer (SDU user): no changes — SDU automation + EWR manual order records, as previously shown. Man-made/polyester producers have NO sliver delivery unit.
Standup extras: Binh testing canvas settings + product modules (found issues, reported); Nathan fixing minor issues on canvas.

Flows shown for the first time (recap at 47:10)

Scanner update — supply-chain information, shipping data connects things in this model.
Claim process — purchase orders → ready to claim → claims.
Evidence pack + how evidence packs are shared.

Open questions / to clarify day-by-day

[x] The 3:53–40:00 segment — RESOLVED 2026-07-09: first reconstructed from source (2026-07-09-claims-and-product-flow.md), then fully captured from screenshots (see “Middle segment” above). Demo narrative matches the source-derived flow (PO → link verifications → notify → retailer confirms → packs + certificate).
[ ] Certificates: TWO attach points now known — (a) manufacturer attaches certificates when linking verifications to a PO, (b) programme-owner certificates flow onto evidence packs. Still open: exact data model for MULTIPLE certificates per transaction and what “connected sub-tiers” means for certificate visibility/inheritance (Malcolm was still reworking this at demo time).
[ ] Supply-chain visibility logic: non-partner suppliers with scans currently don’t appear on the supply-chain page — Malcolm said “I do need to check the logic on this one”. Confirm final rule (also the partner=name+location / non-partner=city+country rule needs Jamie confirmation). — PARTIAL (2026-07-16, source): current source shows non-partner suppliers with scans DO appear, masked as “Confidential supplier” + “Invite partner” CTA (useRetailerSupplyChain.ts:182-205, RetailerSupplyChain.tsx:68-78) — CONTRADICTS the demo claim. Display rule CONFIRMED: identity masked, but city/country always shown regardless of partner status (useRetailerSupplyChain.ts:186-196). FINAL intended rule still Malcolm’s to confirm. See 2026-07-16-code-resolved-open-questions.md §1.3-1.4.
[ ] Data connections vs sharing: Malcolm’s final decision on whether verification sharing folds into data connections.
[x] Programme details CRUD bug — is the fix in Lovable yet? — RESOLVED (2026-07-16, source): PARTIALLY fixed and now a deliberate permission split, not a bug. Programme owner CAN edit logo (upload/replace/remove) + supplementary “program items” full CRUD (OwnerProgramRecord.tsx:127-141,77-118); core fields (name/description/dates/fibre/country/status) are read-only for owners BY DESIGN — admin edits them under /admin/programs (AdminProgrammes.tsx:725-836).
[ ] Which of the admin/CMS override functions (programme logo/wording) are in scope for monet (admin is currently OUT of dashboard scope per feedback_dashboard_mvp memory).
[ ] What exactly Vu’s “updated APIs for Nghia to integrate” covers — get the list.