01_ASRs¶
01_Architecture_Significant_Requirements_v1¶
Product: PackyTrace.
What this document is¶
Architecturally Significant Requirements (ASRs) are the requirements that pass two filters at once: they would sink the business if unmet, and the architecture is what makes or breaks them. A requirement that is fatal but that no design choice can save — whether brands believe the compliance-as-marketing story, whether the team holds together, whether funding comes through — is not an ASR. Those are real risks, but they live in the Conditions of Satisfaction and the Project Overview, not here. This document covers only the things the architecture itself has to get right.
ASR-1 — Get data in from any source without rewriting the system¶
Product data comes from sources we do not control and that will keep changing: Open Food Facts, plus at least one real producer source via API, scraping, or manual upload. Incumbent infrastructure providers have every incentive to keep their data closed, which is why this is our stated #1 business risk. If adding or fixing a source means re-plumbing the system, a part-time team cannot keep up, and the raw material the whole product is built from dries up. Sink condition: no data, no product. Serves: CoS #4. Every brand onboarded under #6 and #8 rides on it.
ASR-2 — The scan-to-view moment must be fast and effortless on a phone in a store¶
Scan → resolve → personalized view is the product. It happens in the real world: someone holding a package in a shop aisle, on their own phone, with whatever signal they have. If it is slow, or it breaks on a common phone, or it asks too much of them, they never come back — and "consumers will use it" is disproven on the spot. What the architecture does: the scan path is the one path we tune for responsiveness and reliability. No login stands in front of it — a first-time scanner gets value immediately, with no account required. The consumer side is built and tested against real phones and real conditions, not ideal ones. Sink condition: a bad scan moment means no return engagement, and the headline consumer signal collapses. Serves: CoS #7, and the consumer side of #6.
ASR-3 — Every scan must be measurable from the very first one¶
We cannot prove a retention signal we did not capture. There is no back-filling behaviour that already happened. The catch is subtle: we could genuinely succeed at retention and still fail the gate because we cannot show it cleanly. And our identity is deliberately anonymous and device-based, which is fragile for retention math — cleared cookies, a second phone, or a shared device each look like a brand-new person. What the architecture does: every visitor gets a stable invisible ID the moment they first scan, before any account exists. All activity hangs off that invisible ID — not off the phone, not off the account. The phone and the account are simply two ways of pointing at the same invisible ID. When someone later makes an account, the account is connected to the invisible ID they already had, so earlier scans carry over with nothing lost and nothing double-counted. This one piece of indirection is cheap on day one and painful to bolt on later, and it is what lets us report a retention number we can defend (the account cohort) alongside an anonymous floor we know undercounts. Sink condition: no clean proof of return engagement means no credible funding decision. Serves: CoS #7 — specifically, it is what makes that condition provable rather than merely true.
ASR-4 — Consumer data must never cross into the brand view¶
Brands receive anonymized aggregates only. The wall between consumer data and the brand dashboard is the legal boundary (GDPR) and the trust boundary the entire pitch rests on. A leak here is a legal event and it destroys the exact relationship we are selling. Now that an account exists, the wall also has to hold back account details — an email and the like — not just behavioural data. What the architecture does: one clear seam separates consumer PII from brand-facing aggregates, built in from the start rather than patched on. Brands see counts and aggregates and nothing else; account details stay on the consumer side of the seam. The wall is two-dimensional: consumer data never crosses to brands, and one brand's data never crosses to another — every brand-owned record carries a tenant ID, with isolation enforced at a single query layer (ADR-001). Because this clause also lives inside the MVP definition, the privacy wall and the data/IP position are kept consistent with each other. Sink condition: a single breach can end the company. Serves: CoS #5, and the privacy clause in #6.
ASR-5 — Change must stay cheap and deploys near-instant¶
We run a two-week adaptive cycle for six months, against a self-funded €500 budget and hard dated gates. Every cycle reshapes the backlog. If the system is rigid, or slow to ship, we cannot act on what we learn before the runway and the cash run out — and validation is the only thing this whole effort exists to do. What the architecture does: a simple modular monolith on a managed platform — deliberately not microservices — that deploys in seconds, because we redeploy every cycle. We lean on managed auth, hosting, and database, and build only what is differentiating. The structure is kept stack-agnostic so the cycle-1 tech choice can favour whatever ships fastest without locking us in. Note (2026-06-11): the structure decision was later revised — the implementation deploys the services independently from the start (ADR-007); the cheap-change driver now leans on one-command compose, shared infrastructure and per-service independence instead of a single deployable. Sink condition: slow or expensive change means we burn the runway without validating anything. Serves: the Adaptive PMLC itself, and CoS #12.
What we deliberately do not architect for¶
Scalability and performance are deprioritized on purpose. At roughly 50 consumers and 3 brands, scale failing would not sink anything — so over-engineering it would waste the budget and pull effort away from validation. If we hit strong signals and commit full-time, this is the first thing we revisit. Until then, it stays off the list.