Walkthrough #2 — 2026-07-09: scan-linking permissions, retirement scope, partial claims

Source: transcript screenshots of the 2026-07-09 standup + Q&A (attendees: Malcolm, Jamie Peel, Hung, Vu, one unlabeled speaker (likely Binh); Nathan absent; Nia absent). Hung drove a live self-test of the Tier1→Tier0 claim flow and asked the questions; Malcolm’s answers below are the most precise statements of claim-linking business logic so far. Cross-refs: [[2026-07-08-malcolm-walkthrough-demo]], [[2026-07-09-claims-and-product-flow]].

Process / timeline updates

Malcolm spent 2026-07-08 mapping functional gaps in the MVP — early-built areas no longer match the (much-changed) methodology. Before dev: heavy cleanup + iron out functionality. He cloned/backed up the MVP so Jamie can merge the UX/UI now (green light from Shannon; Jamie proceeds in the same environment; Shannon OK’d Jamie’s personas + empty states).
Evidence packs status: 3 packs under the claim structure — one near done (minor items), one halfway, procurement pack untouched. Malcolm + Jamie splitting the work. Shannon is taking the pack views to a trusted industry expert — “it’s a sort of $1,000,000 certificate we’re trying to generate”. Target: done this week, Shannon review early next week.
Malcolm demoing to Julianne, Aaron, Sovik (2-3pm UK) — they last saw the “Max version” 4-5 weeks ago.
Session planned with Nghia (+ Hung) to review the Lovable front-end code: goal = export from Lovable with business logic + data model already correct; Nghia then wires API separation, call optimization, page loads; Jamie checks responsiveness. Explicit: pages do NOT need to work well on mobile.
Explicit warning repeated: don’t take current designs into dev “other than for play” — things will change; lots of backend tidy-up first. Malcolm: “I’m getting tired of doing the iterations, so I want to get into dev.”
Later Jamie discussion topics: bale ID tracking to serialise data on the scan process (Malcolm has improvement ideas) + partial-scan inconsistencies + legacy verification-sharing (whether it goes into this UI).
Team asked Malcolm to enable downloading recordings/transcripts (pending).

Scan→claim linking rules (Hung’s test + Malcolm’s answers) — CORE LOGIC

Hung’s repro: logged in as Tier 1, did an outbound verification (5 scans) with recipient = a DIFFERENT company (Sundown), then as Target (Tier 0) created an evidence request (PO, 50 t) to that Tier 1. When linking verifications as Tier 1, he could still select the scans addressed to Sundown — expected a permission block.

Malcolm’s rulings:

DELIBERATE: a manufacturer may attach ANY scan done at their own facility (inbound or outbound), regardless of who the outbound was addressed to. Not a bug. Real-world case: importation happens at a sub-tier while the finished product is made in-country (e.g. Target has fabric made in Vietnam but garments cut-and-sewn in the US) — so the scans backing a claim may not be addressed to the claiming brand. Quote: “You can send a scan to somebody else and put that on a claim certificate. It is a use case we just need to be mindful of.”
Hung’s stricter model (“only scans associated to the claiming partner”) is acknowledged as “the more logical happy path” and a valid position, but Malcolm is NOT restricting it for now. Agreed improvement instead: show the relevant partner (sent-to / received-from) on the scan-selection screen so the operator can tell — Jamie to add.
The linking screen shows only scans done BY that tier-1 company — NOT scans shared with them by sub-tiers. Shared-scans handling in this screen is being tidied by Malcolm+Jamie now (legacy “verification sharing / groups of verifications” exists elsewhere in the platform; deciding whether it comes into this UI).
Tier-level connection, not item-level: the claim does NOT pull over FT IDs / session IDs from connected sub-tier scans. “We just connect it from a tier level… we’re saying a tier 2 was involved, a tier 2 sent it to tier one and the tier one scans were done.”

Retirement scope — the precise rule (refines “claim once”)

On claim confirm, the tier-1’s LINKED scans are retired — cannot be attached to any other claim.
Sub-tier verifications are NOT retired (e.g. the tier-2→tier-1 outbound/inbound pair): that tier-2 scan may legitimately serve multiple other customers — one fabric mill supplies many cut-and-sews / many FibreTrace customers (Lycra, Gore-Tex, Carl Fibre cited as manufacturer-brands selling marked fibre; fabric made speculatively or on demand). Malcolm: “What I’m unable to figure out any logic to do is to retire sub-tier verification, because I don’t know whether that tier 2 scan is going to be used for multiple other customers.” Sub-tier scans stay unlinked/unclaimed — they don’t appear on anyone’s evidence pack, but remain usable in the supply chain “because it never gets associated directly with an individual claim”.
Un-link lifecycle: after tier-1 links (pre-claim), those scans should no longer be linkable again (needs testing). If the retailer REJECTS, tier-1 can go back and change scans. To unlink after linking, the retailer must CANCEL the claim. Once the claim is confirmed, customers have NO ability to modify links.
Chain-of-custody recursion (in progress): once linked, Malcolm needs to “go recursively through all the shared sessions and mark those that they’ve been claimed”. Shannon additionally wants to mark which digital traceability solution is using each piece of evidence so customers can’t put the same claim evidence into multiple traceability solutions (double-claiming across platforms). Design not settled — “he’s coming up with a high-level idea and I’ve got to put something in that’s practical”.

Partial claims

PO for 50 t, claim 25 t → PO shows partial, 50% remaining. Retailer re-submits the PO (“put in the PO again”) → tier-1 proposes another production run against it. PO match will say “you’ve used 50% of it already”. Cannot over-claim the same PO. Malcolm: “We don’t manage inventory — we’re just tracking how much has been claimed.”
Current implementation of partial claiming is “a bit buggy” (also: Jamie’s mock tier-0 shows a “partially claimed” chip inconsistently — vibe-coding regressions, see below).
Display rule: the evidence pack does NOT show partial/full status (irrelevant to the importation process; packs are for external viewing). The claim LISTING page shows partial/claimed chips — and needs improvement so the retailer can reconcile partial-claim scenarios.
Why the tier-1 sets the claim amount, not the tier-0 (Shannon’s ruling): the retailer doesn’t know how much raw fibre went in; only the manufacturer does. A PO is a financial amount (“make me this product for this money”). Canonical example: PO = 1M t-shirts + 1M towels for Q1; tier-1 makes and ships the t-shirts first → evidence pack covers just the t-shirts (half the PO); only the tier-1 knows the fibre quantity used. Retailer-side visibility of “what’s left” is an open UX gap.
One evidence/claim from MULTIPLE tier-1 companies: No. Possible but commercially unrealistic — customer-supplier is one-to-one per PO; two suppliers for the same SKU = two separate POs. Explicitly ignored.

Tier assignment confirmed (+ known modelling risk)

Vu asked how manufacturers get arranged into tiers. Malcolm: tier is NOT derived from the product being verified. It comes from Settings → Company → the self-declared supply-chain-tier field — “that’s the only place we ask them what tier they are”. (Matches the source finding: company_details.supply_chain_tier, free-text.)
Known weakness Malcolm volunteered: one company can be tier 1 to someone and tier 2 to somebody else. Sitex example: vertically integrated (spinning mill + cut-and-sew + own retail brands; 5 factories, each a different function). Arguably tiering belongs at FACILITY level; “we’ve had arguments internally over whether we attach the tier to the company or the facility — we’ve got what we’ve got at the moment. The model I’ve put in might transpire to be wrong.”

AI-tooling / export process (relevant to monet integration)

Lovable can generate explainer files (logic + personas) into its file section; Malcolm reviews them manually and used them for the David/Danny training guide. Caveat from Malcolm: Shannon’s Claude “is still hallucinating a little bit — there’s data fields in one pack that we don’t collect”, so every generated spec is interpreted, not trusted.
Malcolm’s export stance (directly affects our port work): “I want to pull straight out of the MVP as best I can, switch off the features that aren’t required, and build from there. I don’t want another Claude interpreting the business logic — we’ve already done that; the MVP’s purpose is to be executed.” Risk he names: dev-side AI re-interpreting logic differently from the MVP + Shannon’s expectations = unsigned-off business logic. Implication for us: port the Lovable logic FAITHFULLY; don’t redesign flows during integration.
Vibe-coding change-control warning (Malcolm+Jamie’s experience): Lovable “sometimes fixes stuff that wasn’t broken”; changes get silently reverted; must prompt “change this to this and don’t change anything else”. Explains UI inconsistencies like the partial-claim chip.

Open questions

[ ] Will the “show partner on scan-selection screen” improvement land (Jamie)? Affects the verification-linking UI we eventually port.
[ ] Recursive mark-claimed for shared sessions + Shannon’s “which traceability solution used this evidence” marker — design unsettled; watch for schema changes (likely new fields on sessions/session_shares).
[ ] Legacy verification-sharing (share links / groups): does it fold into the claim-linking UI or stay separate? (Carries over from walkthrough #1.)
[ ] Company-level vs facility-level tier — Malcolm admits the model may be wrong; any BE design should anticipate a possible facility-level tier.
[ ] Partial-claim listing improvements + retailer visibility of remaining PO volume — expect UI changes.
[ ] Bale ID tracking / serialising scan data — Malcolm has an improvement plan; new data model likely.