Appearance
Business-domain coverage: what QRSETU can and cannot absorb
Enterprise-architecture assessment, 2026-08-07. Answers: can a dairy onboard; does it need a new archetype; which business types are supportable, which are blocked, by what, and whether each block is a temporary implementation gap or a foundation change.
Companion: scalability assessment §A1 (the dairy test) · data architecture · ADR-0009
0. The distinction that resolves most of the ambiguity
Three different questions get asked as one. Separating them makes every answer below unambiguous:
| Question | State |
|---|---|
| Built — code that runs against Dev today | Onboarding · Setu Card render · catalog CRUD (M8) · capability gating (S1). No orders, no payments, no CRM, no scheduling. |
| Designed — ADR-0020's model as written | Identity/tenancy, public card, feature resolution, catalogue, orders/payments, plans/seats, analytics, ops. |
| Architecturally reachable — designed + the primitives of §A1 | Every vertical in §2 below, as configuration. |
Nothing in this document is a statement about what runs today. It is a statement about what the foundation can absorb without a redesign, which is what the owner asked for.
1. The dairy answer
Yes, and it does not need a new archetype. It needs a second axis that the current model lacks.
Why "does dairy need a new archetype?" is the wrong question
The current model makes archetype the only axis of variation, so any business that does not fit appears to need a new one. That is the flaw, not dairy.
Archetype answers "what do you sell?" — Primitives answer "how does your business run?" These are orthogonal, and collapsing them into one axis is why the model runs out of room.
A dairy sells physical goods from stock, so its archetype is the existing inventory_listing — the same as a boutique or a sweet shop. What distinguishes it is its process composition:
| Requirement | Archetype? | Primitive |
|---|---|---|
| Product catalogue | inventory_listing | Catalogue ✅ designed |
| Setu Card presence | — | core ✅ designed |
| Daily sales tracking | no | Ledger ❌ missing |
| Customer management | no | Party ❌ missing |
| Recurring monthly subscriptions | no | Recurrence ✅ engine exists + Party ❌ |
| Order management | no | Order ✅ designed |
| Payment collection | no | Payments ✅ designed |
| Delivery workflows | no | Schedule + Fulfilment + Resource ❌ missing |
| Stock tracking | no | Ledger (per-period) ❌ — the counter in the design is the wrong shape |
| Customer communication | no | Party + notifications ❌/✅ |
Not one of those is dairy-specific. A gym needs Recurrence + Party + Balance. A tutor needs Schedule + Recurrence + Balance. An AMC electrician needs Recurrence + Fulfilment. Every missing primitive serves at least three verticals — which is exactly ADR-0009's own test for whether a capability is legitimate or mis-modelled.
So the corrected model: archetype becomes a curated PRESET over two axes
industry ──→ archetype (what you sell: primary entity + attribute schema)
╰─→ primitive composition (how you run: which processes are active)Adding dairy is then: one industries row (key='dairy', archetype inventory_listing) + a primitive composition that already exists because gyms and tutors needed it + an attribute schema ({fat_percent, unit, shelf_life_days}). Zero code. That is the ADR-0009 promise actually delivered.
The five existing archetypes are therefore not wrong — they are underspecified, varying only one dimension.
What a dairy owner gets, concretely
Setu Card at qrsetu.com/anand-dairy · catalogue (Full-cream milk ₹66/L, Toned ₹54/L, Paneer ₹80/200g) · customers as Party rows without requiring them to hold QRSETU accounts · standing orders as a recurrence rule with pauses as exception rows ("1L daily, skip Sundays, paused 3–7 Aug") · a daily delivery run generated from those rules · fulfilment marked per delivery, which is what month-end billing must be computed from · a running balance per customer · online payment collection against that balance · manual cash sales in the same ledger as online orders · and a proactive nudge from stored state ("Sharma-ji's balance is ₹1,840, unpaid 12 days").
2. Business types QRSETU can absorb as configuration
Given the designed model plus the §A1 primitives. Grouped by archetype; each row is an industries row and an attribute schema, nothing more.
| Archetype | Verticals | Primitive composition |
|---|---|---|
| inventory_listing | Boutique · dairy (single outlet) · sweet shop · general store · mobile/electronics shop · plant nursery · hardware · festival/Ganapati stall · bakery | Catalogue + Ledger (+ Party, Recurrence, Balance, Schedule where relevant) |
| booking_appointment | Yoga trainer · academic tutor · consultant · physiotherapist · pet groomer · driving instructor · single-operator salon | Catalogue + Party + Schedule + Fulfilment (+ Recurrence for batches/terms) |
| lead_portfolio | Real-estate agent · photographer · electrician · plumber · interior designer · direct seller / MLM distributor · event planner · caterer | Catalogue + Party (early stages) + Fulfilment |
| catalog_informational | Restaurant/cafe menu · temple/trust · school prospectus · NGO · clinic information page | Catalogue only |
| ecommerce_cart | Any of the above selling online with delivery | Catalogue + Order + Payments + Fulfilment |
That is ~30 verticals on five archetypes and seven primitives. The leverage is real — provided the primitives exist.
3. Business types that are BLOCKED, and by what
Ranked by how many verticals each block gates. Three of these were not previously identified anywhere.
🔴 L1 — No LOCATION concept: every multi-outlet business is unrepresentable (new finding)
workspaces is 1:1 with a card. A dairy with two collection points, a boutique with two shops, a tuition centre with three branches, a salon chain — all extremely common in Indian SMB — would today need N workspaces = N cards = N slugs = N subscriptions, with no shared catalogue, no shared customers and no consolidated reporting. That is not a workaround, it is a different (and wrong) product.
Blocks: every chain/branch business, per-location stock, per-location hours, per-location staff. Verdict: FOUNDATION CHANGE. locations must be a first-class child of workspaces, and catalog_items stock, orders, card_hours and resources must all be location-aware from the baseline. Retrofitting a location dimension onto populated stock and order tables is a rewrite. Cost now: ~0.5d. Cost later: weeks.
🔴 L2 — No RESOURCE concept: staff-, room- and vehicle-dependent booking is impossible (new finding)
A salon where you book with a named stylist, a clinic with three doctors, a dairy with two delivery routes, a studio with two rooms. workspace_members exists but models app access, not bookability — and critically, a stylist who does not use the app is not a workspace_member. So there is nothing to book against.
Blocks: multi-staff salons, clinics, co-working, equipment rental, any delivery routing. Verdict: FOUNDATION CHANGE IF DEFERRED, FREE IF ANTICIPATED. Give Schedule a nullable resource_id from day one and add a thin resources(workspace_id, location_id, kind, name) table. Booking against a resource then becomes additive. Cost now: ~0.5d.
🔴 L3 — No TAX model: all B2B and all compliant invoicing is blocked (new finding)
catalog_items.price_minor carries no hsn_sac, no tax_rate, no inclusive/exclusive flag; order_items has no tax breakup. A dairy selling to a shop, any B2B vertical, and any vendor who must issue a GST invoice cannot be served. The 26.0.1 plan tracks GST TCS and commission invoicing as owner-track compliance — but that is QRSETU's own tax posture, not the vendor's item-level tax model, and the latter is entirely absent.
Blocks: all B2B, wholesale, registered vendors above the GST threshold, anyone needing a tax invoice. Verdict: FOUNDATION CHANGE. Tax must be on catalog_items and snapshotted into order_items alongside price. Adding it after orders exist means historical invoices cannot be reconstructed. Cost now: ~0.5d.
🟠 L4 — Integer quantity and no unit of measure
A dairy sells by the litre and 0.5 L is a normal order; sweets sell by kg, cloth by metre. catalog_items has no unit, and if order_items.quantity is an integer the dairy case is broken outright. Blocks: dairy · sweets · groceries · textiles · hardware — a large share of Indian retail. Verdict: cheap foundation change — unit text + quantity numeric(12,3). ~0.25d now, painful after orders exist.
🟠 L5 — transfers is one-order-to-one-payout-account
Co-broking (two agents splitting a commission), agency models, and any genuine marketplace need 1:N splits. Razorpay Route supports multiple transfers; the design models one. Blocks: co-broking real estate · travel agents · sub-contracted services · marketplace. Verdict: cheap now — make transfers a genuine 1:N child of orders with a sum CHECK. ~0.25d.
🟡 L6 — No realtime: queue/token, chat and live status are impossible
Supabase Realtime appears nowhere in the design. A clinic's token display, a restaurant's table/KOT status, consumer↔vendor chat all need it. Blocks: clinics · restaurants (dine-in ops) · any live-queue business · the consumer chat workflow. Verdict: TEMPORARY implementation gap. Additive — tables plus enabling a Supabase feature. No foundation change, provided the tables are designed append-only with a stable ordering key.
🟡 L7 — No credential-verification workflow for regulated verticals
industries.compliance_profile jsonb is designed, which is the hard part. What is missing is the process: a document store, an admin review queue, a verified badge, and enforced disclaimers. Blocks: doctors · CAs · lawyers · insurance agents · loan agents — high-value segments, and shipping them unverified is a liability rather than a gap. Verdict: TEMPORARY. The compliance_profile column plus the admin panel's review queue covers it. It also unblocks ADR-0004's ad-restriction fail-closed and QRS-086.
🟡 L8 — No batch/lot or expiry tracking
Legally required for pharmacy; useful for dairy and packaged food. Blocks: pharmacy · agri-input dealers · anything with statutory traceability. Verdict: TEMPORARY — an additive catalog_item_lots table once Ledger exists.
4. Temporary gap vs foundation change — the summary the owner asked for
| # | Limitation | Verdict | Cost if done in the baseline | Cost if deferred |
|---|---|---|---|---|
| L1 | No location / multi-outlet | FOUNDATION | ~0.5d | Weeks — rewrites stock, orders, hours |
| L2 | No bookable resource | FOUNDATION if deferred | ~0.5d | Re-models the whole scheduling layer |
| L3 | No tax model | FOUNDATION | ~0.5d | Historical invoices unreconstructable |
| L4 | Integer qty, no UoM | Cheap foundation | ~0.25d | Painful once orders exist |
| L5 | 1:1 transfers | Cheap foundation | ~0.25d | Money-path migration |
| L6 | No realtime | Temporary | — | Additive any time |
| L7 | No verification workflow | Temporary | — | Additive any time |
| L8 | No batch/lot | Temporary | — | Additive once Ledger exists |
| §A1 | Five missing primitives | FOUNDATION | ~+3.0d design, ~+2.5d impl | Multiples — Party/Ledger are referenced by orders, analytics, CRM |
Five items are cheap now and structurally expensive later (L1–L5, ~2.0d total). Three can wait indefinitely with no penalty (L6–L8). That is the entire actionable content of this assessment.
5. The revised extension model
What "onboard naturally through configurable features" means once the above lands:
| To add… | You write | You do NOT write |
|---|---|---|
| A new vertical (dairy, pharmacy, gym) | One industries row + attribute schema + primitive composition | Any code |
| A new process (a genuinely novel workflow) | One primitive, once, reusable by every vertical | A per-vertical implementation |
| A new plan / entitlement | feature_grants rows | Any code |
| A new archetype | Rare — only when the primary entity is genuinely new | — |
The test for whether a proposed primitive is legitimate is ADR-0009's own: it must generalise to at least three verticals. Party, Schedule, Recurrence, Fulfilment, Ledger, Balance, Location and Resource all pass. A "milk round" primitive would not — it is Schedule + Recurrence + Fulfilment + Resource, and recognising that is the difference between a platform and a pile of verticals.
6. What is NOT reachable, and should be refused rather than promised
Stated so these are declined deliberately rather than half-built:
- Full ERP — manufacturing BOMs, multi-warehouse transfers, payroll, double-entry accounting. Adjacent but a different product;
Ledgeris a business ledger, not a general ledger. - Regulated financial services — lending, insurance underwriting, deposit-taking. RBI-licensed activity; ADR-0020 must never drift toward holding customer funds (the RBI PA constraint the plan already names as its most easily-broken guardrail).
- Healthcare records (EMR/EHR) — clinical data has its own regulatory regime. A clinic can have a card, a catalogue and appointments; it must not have patient records.
- Food-delivery logistics at aggregator scale — live rider tracking and dispatch optimisation is a different systems problem.
Each of these is a product boundary, not an architectural one — which is why they belong in a written list rather than in the schema.