Archetype Business Value Streams

Status: Draft — 2026-07-18 (catalog sweep applied; 95/21 source catalog reflected) Kind: Planning artefact (architecture + testing + archetype documentation) Owner surface: Architecture feature (/ea), archetype documentation, and the archetype audit. Consumed by: archetype-audit-plan.md · the EA / architecture feature · per-archetype documentation. Implemented by: 2026-06-12-value-stream-architecture-platform-design.md — platform design that captures these value streams as architecture, measures/optimizes each archetype’s business model, and drives coworker facilitation + proactivity (the how). Grounded in: packages/storefront-templates/src/archetypes/ (95 seeded archetypes across 21 categories as of 2026-07-18) and packages/storefront-templates/src/types.ts (operating-model axes, commercial models, activation profiles). Decision authority: Defines value-stream interpretation, audit severity rationale, EA rendering semantics, and archetype documentation language. It does not override seed data, create new runtime tables, or authorize WWMD/WWWD perspective blending.

0. Why this document exists

The archetype audit drives 95 seeded archetypes through a browser-realistic experience and records gaps. The risk it names in its own Section 1 — “The platform must behave correctly for each organizational model” — is that testing becomes arbitrary: we click through phases A–H because the checklist says so, not because each click defends something the business actually depends on.

This artefact removes the arbitrariness. It states, for every archetype, the operational value stream the business runs in the real world — the end-to-end sequence of value-adding stages that turns a stranger into a served, paid, retained customer. Every test phase then exists to validate a named stage of a real value stream, and every finding can be tied to the stage of the business it threatens. A vet booking form that drops the pet fields is not “an important finding because the checklist says pet fields” — it is a break in the Capture-Demand → Deliver-Care handoff that makes the clinic’s core value stream non-functional.

Four consumers, one source of truth:

1. Testing & validation — the audit phases map to value-stream stages (Section 4). A finding cites the stage it breaks; severity follows from how load-bearing that stage is for the archetype.
2. Architecture feature — the value streams render against the substrate the platform already carries (OperatingModelAxes, ActivationProfile, It4ItStage, PortfolioDecomposition) and export to ArchiMate (Section 8).
3. Archetype documentation — each archetype’s “how this business actually works” narrative (Section 6) is the human-readable answer to why its storefront, vocabulary, scheduling, finance, and compliance defaults are shaped the way they are.
4. Business-context decision substrate (WWWD) — the value-stream architecture and its concerns are foundational input to the org’s own “What Would We Do” decision perspective: the governed profile of how this business operates and decides. See Section 8.8 for the WWWD-vs-WWMD context separation.

Reader contract. This document is deliberately both architectural and operational. Architects use it to bind value stages to capabilities and export semantics. Testers use it to justify severity. UX designers use it to decide what the operator should see first. Business analysts use it to turn a vague gap (“booking feels wrong”) into a stage-specific requirement with acceptance evidence (“S3 Schedule ignores provider capacity for an appointment-checkout business”).

1. Two senses of “value stream” — keep them distinct

The platform already has a canonical Value Stream entity. It means the IT4IT v3 seven cross-cutting flows — Evaluate, Explore, Integrate, Deploy, Release, Operate, Consume — i.e. how DPF itself builds and runs digital products. That is the producer/platform value stream and it is unchanged by this document.

This document is about the other sense: the operational value stream of the customer’s business — how a salon, a bank, or a town creates and delivers value to its own end customers. The two relate cleanly:

Standard used (research-and-use-standards): ArchiMate defines a value stream as a sequence of activities that creates an overall result for a customer, stakeholder, or end user (Open Group ArchiMate 3.2 reference card). The Business Architecture Guild frames business architecture value streams around customer and stakeholder value, with stages that realize value items and cross-map to capabilities (Guild white paper, 2019). DPF uses those standards together: stages describe stakeholder value accrual; capabilities describe what the platform must provide to enable each stage.

This distinction matters. A value stream is not a click path, process map, or implementation workflow. A value-stream stage may be realized by multiple UI flows and processes, and one UI flow may touch multiple stages. The stage names therefore stay stable even when the portal design changes.

The bridge: the customer’s operational value stream lives almost entirely in IT4IT’s Consume stream (request → fulfilment → customer-facing experience). DPF’s job is to make a non-technical operator run their whole operational value stream through the platform’s Consume surface. So this document is the detailed expansion of “Consume” for each of the 95 businesses we ship.

2. The universal small-business value stream

Across all 95 archetypes, the same backbone recurs. Differences are not which stages exist — every business attracts, captures, delivers, settles, and retains — but which stage is load-bearing, what “value delivered” means, and which trust gate governs it. The backbone:

                 ┌─────────────────── TRUST & COMPLIANCE (cross-cutting) ───────────────────┐
                 │                                                                            │
  S1 ATTRACT  →  S2 CAPTURE  →  S3 QUALIFY  →  S4 DELIVER  →  S5 SETTLE  →  S6 RETAIN
  & Discover     Demand          & Schedule     the Value      & Account     & Grow
                 │                                                                            │
                 └────────────────── OPERATE & IMPROVE (cross-cutting) ──────────────────────┘

Primary stages

Cross-cutting concerns (govern every stage; failures here are not optional polish):

• Trust & Compliance — the right vocabulary (patients, members, ratepayers, borrowers), the right disclosures (FDIC, NMLS, gift-aid), and the refusals a regulated business needs (no clinical/legal/financial advice; no CJI access). For licensed archetypes this is load-bearing in S1–S2 already — the offer is not legible if it is not compliant.
• Operate & Improve — the coworker and the ops backlog: the always-on operator’s assistant that must speak the business’s language, never the platform-developer’s, and convert demand into operational work.

Reading guide: a stage is load-bearing for an archetype when a defect there makes the business non-functional, not merely inconvenient. The per-category profiles (Section 6) name the load-bearing stage(s) for each archetype. Audit severity should track this: a defect in a load-bearing stage is critical/important; the same class of defect in a non-load-bearing stage is minor.

3. The commercial model decides the value-stream shape

The single axis that most changes the shape of the stream is OperatingModelAxes.commercialModel (see types.ts). It determines what S2/S5 look like and where the load-bearing stage sits. The eight shapes we actually ship:

This table is the why behind the audit’s CTA-by-CTA Phase B5 scripts and the Phase G financial variants. It also explains the audit’s three “full fresh install” rules (banking, MSP, public sector / law enforcement): those are exactly the models whose trust gate precedes the value stream, and a swap does not re-provision the gate.

4. The bridge — value-stream stage → platform surface → audit phase

This is the table the audit refers to when executing. It makes every phase non-arbitrary: each one defends a named stage. ([A] = archetype-specific evaluation target; [C] = common mechanic proven once in Run 0.)

Severity derivation rule for the audit: locate the finding’s stage in Section 6’s per-archetype “load-bearing stages.” A defect in a load-bearing stage → critical (flow broken / wrong data) or important (missing field/label/module). The same defect in a non-load-bearing stage → minor. This replaces ad-hoc severity calls with a stated rationale.

5. The value-stream stages map onto substrate the platform already carries

Nothing here invents a new table. The stages bind to existing fields, which is what lets the architecture feature render them (Section 8) and the audit read expected values from seed rather than from prose.

The PortfolioDecomposition already tags each portfolio role with It4ItStage[] — that is the formal seam where the operational value stream (this doc) plugs into the platform value stream (the kernel entity). An archetype’s productsAndServicesSold portfolio carrying it4itStages: ["request-to-fulfill"] is the machine-readable assertion that this business’s S2–S5 live in Consume.

5.1 Architecture and usability invariants

These invariants keep this artefact useful to architecture, UX, testing, and business analysis without turning it into a parallel product model:

Usability consequence. The EA surface should not present a dense architecture diagram as the first experience for an operator. The default view should be a short stage ribbon with the load-bearing stage, trust gate, and next operational action visible. Capability bindings, IT4IT joins, and ArchiMate details are drill-down material for architects and admins.

6. Per-category value-stream profiles (all 95 archetypes across 21 categories)

The field-dispatch leaves folded into existing categories on 2026-06-13 (e.g. hvac-contractor, home-health-care, mobile-pet-grooming) share their category’s value-stream profile below and are catalogued — with their cross-category pattern — in §10.2. The three dispatch-native categories are §6.16–6.18; media-production and live-events-venues are now first-class profiles in §6.20–§6.21.

Each profile gives: the value the end customer receives (job-to-be-done), the commercial model (Section 3 shape), the load-bearing stage(s), the distinctive stage that the audit must scrutinise, and the trust gate. Per-archetype rows name only what diverges from the category. Service names and CTA labels are expected from seed — where prose and seed disagree, seed wins.

6.1 Trades & Maintenance (Run 1) — plumber, electrician, facilities-maintenance, landscaping, cleaning-service

• Value delivered: a property problem is fixed or kept-from-breaking — competently, on time, often urgently.
• Commercial model: quote / inquiry-to-engagement (facilities-maintenance and cleaning-service add recurring-agreement for planned contracts).
• Load-bearing stage: S2 Capture — the inquiry must capture enough to quote and triage (jobType, urgency Emergency/Routine/Planned, propertyType). A leak at midnight that lands as a content-free “contact us” is a lost job.
• Distinctive stage: S3 Qualify — urgency drives dispatch order; emergency vs planned is the whole economics of trades.
• Trust gate: licensed trades (electrician — EICR/NICEIC; gas) must frame certification correctly; coworker must not improvise safety/compliance advice.
• Value-stream-critical assertions: TRADES_FORM_FIELDS (urgency, propertyType) render and submit; inbox shows urgency so dispatch can prioritise; coworker says “jobs/call-outs/quotes/technicians,” never “appointments/products.”

6.2 Beauty & Personal Care (Run 2) — hair-salon, barber-shop, nail-salon, beauty-spa, personal-trainer, mobile-beauty

• Value delivered: a personal-care service performed by a specific practitioner in a specific slot.
• Commercial model: appointment-checkout — book and pay at service; no running account/estate.
• Load-bearing stage: S3 Schedule — the calendar is the product. Practitioner availability, operating hours, slot length, and no-show buffers are the business. A booking that ignores the stylist’s real hours is a broken business.
• Distinctive stage: S2 → S3 handoff: provider selection must show that provider’s slots, not generic ones.
• Trust gate: low for the salon/spa/training leaves; mobile-beauty inherits the field-dispatch pattern in §10.2.
• Value-stream-critical assertions: customer-estate module is NOT active (appointment-checkout); coworker confirms “no account balance — pay at time of service”; duration variants render (spa 60/90 min); vocabulary “clients/appointments/stylists,” not “patients/members.”

6.3 Healthcare & Wellness (Run 3) — veterinary-clinic, dental-practice, medical-practice, physiotherapy, counselling, optician, plus medical-mobile leaves in §10.2

• Value delivered: an episode of care for a patient (or pet) whose history must inform the encounter.
• Commercial model: encounter-based; provisioning episode-of-care.
• Load-bearing stage: S4 Deliver — the encounter is only safe/useful if the record (patient/pet, history, reason for visit) is present. This is why customer-estate + ConfigurationItem (pet) are the spine.
• Distinctive stage: S2 must capture the clinical subject — pet fields for vet, patient identity for dental/physio. A vet booking with no pet fields breaks the whole stream (audit logs this critical).
• Trust gate: highest in the consumer set — coworker stays in scheduling/operational territory, never diagnoses or triages clinical/mental-health crises; counselling crisis → route to emergency services.
• Value-stream-critical assertions: pet/patient fields render on the booking form and surface on the inbox record; “patients/owners/appointments” vocabulary; initial-assessment slot longer than follow-up (physio scheduling defaults); invoice ties to the patient record (S5↔S4).

6.4 Pet Services (Run 4) — pet-grooming, pet-boarding, dog-walking, plus mobile pet leaves in §10.2

• Value delivered: care for a named pet whose details (size, breed, temperament) shape the service.
• Commercial model: appointment-checkout with an encounter-like estate (the pet record).
• Load-bearing stage: S4 Deliver informed by the pet record + S3 Schedule (multi-night for boarding, recurring for walking).
• Distinctive stage: S3 varies sharply — grooming is a slot, boarding is a date range, dog-walking is a recurring booking.
• Trust gate: low; operational only.
• Value-stream-critical assertions: pet ConfigurationItem carries to the inbox booking; size-based “from” pricing renders (grooming); multi-night date-range flow (boarding); recurring vs one-off distinction the coworker understands (walking).

6.5 Food & Hospitality (Run 5) — restaurant, catering, bakery

• Value delivered: food — reserved (restaurant), commissioned for an event (catering), or bought (bakery). Three different streams in one category.
• Commercial model: booking (restaurant), quote/inquiry (catering), transactional/point-of-sale (bakery).
• Load-bearing stage: restaurant S3 (table/party-size/meal-service slot); catering S2 (event type/date/guest-count quote); bakery S2 (catalog → cart → checkout).
• Distinctive stage: the mixed CTA — the category proves the platform can host booking, inquiry, and purchase side by side; bakery’s custom-cake commission is an inquiry-style sub-flow inside a purchase archetype.
• Trust gate: allergen/dietary capture is a duty-of-care surface (restaurant/catering).
• Value-stream-critical assertions: party-size field (restaurant) renders and reaches inbox; single vs dual operating window (lunch/dinner) — log single-window as a minor S3 gap; “Shop/Order” not “Book” (bakery); commission sub-flow submits to inbox.

6.6 Retail & Goods (Run 6) — retail-goods, artisan-goods, florist, wholesale-distribution

• Value delivered: a physical good acquired (retail/artisan/florist) or a trade supply relationship opened (wholesale).
• Commercial model: transactional/point-of-sale — except wholesale-distribution, which is inquiry (trade-account/bulk-quote), the deliberate B2B exception in a retail category.
• Load-bearing stage: S2 Capture — catalog → product detail → cart → checkout → order reference must not drop a link; S6 the customer/account linkage that turns a buyer into a repeat customer.
• Distinctive stage: delivery logistics enter S4/S5 — florist needs delivery date/address for perishables; artisan commission and workshop are sub-flows (inquiry + booking) inside purchase.
• Trust gate: low (consumer goods); wholesale adds trade-account verification.
• Value-stream-critical assertions: “Shop Now” label; image placeholders not broken tags; order links to the customer account (S2→S6); wholesale renders inquiry (“trade customers/accounts”), not “Shop Now.”

6.7 Fitness & Recreation (Run 7) — gym, yoga-studio, dance-studio

• Value delivered: ongoing access to facilities/classes via membership.
• Commercial model: subscription — recurring, not one-off.
• Load-bearing stage: S6 Retain — the renewal and the membership lifecycle are the business, not the first join. Day passes are the transactional on-ramp.
• Distinctive stage: S5 must express recurring billing language, not a single purchase; class schedules (yoga) are a class-pattern S3 sub-surface.
• Trust gate: age/DOB and emergency-contact capture for membership; low regulatory.
• Value-stream-critical assertions: coworker frames subscription/auto-renew, never “appointment-checkout”; “members/students” vocabulary (gym/yoga/dance); membership tiers render with recurring price language.

6.8 Education & Training (Run 8) — corporate-training, tutoring, driving-school, music-school

• Value delivered: a learner gains a skill — delivered 1:1, in cohorts, or as a B2B programme.
• Commercial model: booking (tutoring/driving/music), inquiry (corporate-training, B2B).
• Load-bearing stage: S3 Schedule for the 1:1/cohort bookings (instructor assignment, term enrolment); S2 for B2B programme inquiries.
• Distinctive stage: the subject is a third party — parent books, student is delivered to (age/year-group/instrument/level fields). Term-based enrolment vs drop-in is an S3/S6 distinction.
• Trust gate: safeguarding tone for minors; B2B (corporate) frames to L&D/HR with “delegates/participants,” not “customers.”
• Value-stream-critical assertions: learner-vs-payer fields render; instructor/pickup-location captured (driving); B2B framing for corporate-training.

6.9 Professional Services A (Run 9) — consulting, legal-services, marketing-agency, accounting

• Value delivered: expertise applied to a client’s problem under an engagement/retainer.
• Commercial model: quote/inquiry-to-engagement; retainer/project-milestone billing in S5.
• Load-bearing stage: S2 Capture quality then S6 Retain (retained advisory, ongoing engagements compound the relationship).
• Distinctive stage: S5 is retainer/milestone, not point-of-sale; B2B vocabulary throughout (“clients/engagements/retainers/deliverables”).
• Trust gate: legal-services and accounting are regulated — coworker must not give legal/financial advice; “consult a qualified solicitor/accountant” framing.
• Value-stream-critical assertions: “clients” not “customers”; regulated disclaimers; portfolio/case-study section (marketing); strict estate separation not active (standard profile).

6.10 Professional Services B — IT MSP (Run 10) — it-managed-services

• Value delivered: a client’s IT estate is kept running and secure under a recurring agreement, with each client’s data isolated.
• Commercial model: recurring-agreement; profileType: managed-service-provider; channel-partner delivery.
• Load-bearing stage: S4 Deliver under strict estate separation + S6 the agreement lifecycle. The whole archetype exists to prove multi-client isolation.
• Distinctive stage: every stage is per-client-scoped; the customer graph is a separate-customer-projection; modules customer-estate, service-agreements, service-operations, projects, lifecycle-signals, integrations are all active.
• Trust gate: estate-isolation correctness is the trust gate (one client must never see another’s assets/tickets).
• Value-stream-critical assertions: onboarding a new client invokes service-agreement + estate-isolation + asset-discovery framing, not “add a customer”; an access-issue report triggers incident/helpdesk framing; vocabulary “clients/agreements/incidents/tickets/assets/estate.”

6.11 Nonprofit & Community (Run 11) — charity, pet-rescue, animal-shelter, community-shelter, sports-club, cooperative, agricultural-cooperative, plus meal-delivery-program in §10.2

• Value delivered: a cause is advanced by a supporter’s gift — or, for cooperative, member-owners govern a shared enterprise.
• Commercial model: donation (charity/rescue/shelter/community leaves) / inquiry-membership with member-owned governance (cooperative and agricultural-cooperative) / membership/community participation (sports-club).
• Load-bearing stage: S2 Capture plus the deliberate absence of S5-as-purchase — a donation issues a receipt, never an invoice/billing account. An auto-created invoice is a stream defect (important).
• Distinctive stage: the value stream intentionally omits commerce artefacts; cooperative adds a governance value stream (member meetings, surplus distribution, share purchase).
• Trust gate: sensitive vocabulary — “supporters/donors/beneficiaries/guests,” never “customers”; gift-aid/tax-relief language (UK); cooperative uses member-democratic framing.
• Value-stream-critical assertions: “Donate” CTA; amount selection renders; no invoice generated; cooperative customVocabulary “Members” renders and governance framing answers “how do I call a special general meeting?”

6.12 HOA & Property Management (Run 12) — homeowners-association, condo-association, property-management-company

• Value delivered: a community/property is governed and maintained on behalf of residents/owners.
• Commercial model: inquiry (dues, maintenance requests, reservations); HOA dues are levy-like.
• Load-bearing stage: S2 Capture of maintenance/violation/reservation requests with property/unit context + S3 routing to the right party.
• Distinctive stage: dual audience — property-management-company serves landlord clients (B2B) and tenant users (B2C) in one stream; coworker must switch framing.
• Trust gate: “residents/homeowners/unit owners,” not “customers”; covenant/dues language.
• Value-stream-critical assertions: “residents” vocabulary; maintenance request carries property address + urgency; shared-facility booking works as a booking sub-flow (condo amenity room); dual landlord/tenant framing (property-management).

6.13 Software & Platform (Run 13 / folded into Run 0) — software-platform

• Value delivered: an enterprise evaluates and adopts the platform — DPF’s own dogfood meta-case.
• Commercial model: inquiry (demo/pilot/partnership); platform ecosystem.
• Load-bearing stage: S2 Capture (inquiry → backlog) and the Operate & Improve loop — inquiry “Send to product backlog” creates a BI linked to the digital product.
• Distinctive stage: the meta-case — the coworker must frame DPF as the product, not the container; no circular “what is DPF?” confusion.
• Trust gate: vocabulary “users/developers/enterprise customers/pilots,” not “patients/members.”
• Value-stream-critical assertions: inquiry → inbox → backlog → BI linked to the digital product; no recursion confusion.

6.14 Banking & Financial Services (Runs 14a–c) — community-bank, credit-union, mortgage-lending

• Value delivered: a financial relationship is opened and serviced — deposits/lending (bank), member share accounts (CU), loan origination (mortgage).
• Commercial model: account-based-fees, provisioning account-with-kyc, billingReadinessMode: prepared-not-prescribed (DPF records fee obligations, never moves money — engagement layer only; core banking stays with the institution).
• Load-bearing stage: the Trust gate before S3 — KYC, disclosures (FDIC/NCUA/NMLS), and BIAN-anchored capability map gate the whole stream. This is why each gets a full fresh install (a swap doesn’t re-provision the gate).
• Distinctive stage: S1/S2 carry mandatory disclosure sections; the EA tool exposes the BIAN capability perspective (Loans and Deposits, Relationship Management, Compliance); strict estate separation + separate customer projection.
• Trust gate: the entire archetype. Coworker cites specific regulation (FDIC Part 328), references KYC steps, gives no rate/legal advice.
• Value-stream-critical assertions: BIAN perspective in /ea; correct regulatory pack (FDIC vs NCUA vs NMLS/RESPA/TILA); customVocabulary renders (“Become a Member”/”Borrowers”/”Share Accounts”); no Donate/Book/Cart anywhere; “Apply” CTA on lending items.

6.15 Public Sector & Law Enforcement (Runs 15–16) — small-town-municipality, municipal-utility, law-enforcement-agency

• Value delivered: a statutory service is rendered to a resident under a universal-service obligation — no profit motive.
• Commercial model: statutory-fees-and-levies; GovernanceModel: public-body; primary consumer resident.
• Load-bearing stage: the Trust & universal-service obligation cross-cut — the service must be available to every resident, fee schedules are set by ordinance/statute, and (law enforcement) sensitive-data refusals are absolute.
• Distinctive stage: S2 is a civic request (permit, records/FOIA, 311 service, service connection) not a sale; S5 is a statutory fee schedule, not a market price.
• Trust gate: “residents/constituents/ratepayers,” not “customers”; correct regulatory references (SDWA/NPDES for utility; POST/CJIS for police); law enforcement: no CJI access in Phase 1 — coworker firmly declines to look up arrest/warrant/dispatch data.
• Value-stream-critical assertions: resident/ratepayer customVocabulary renders; statutory-fee framing; SDWA/NPDES (utility) and POST/CJIS (police) compliance placeholders; police coworker declines CJI lookups and routes complaints to the intake flow without legal opinion.

6.16 Automotive Services (field-dispatch) — auto-glass, mobile-mechanic, mobile-detailing, mobile-tire, roadside-assistance, locksmith

• Value delivered: a technician travels to the customer’s vehicle (driveway, workplace, roadside) and restores it — glass, mechanical, cosmetic, mobility, or access. Field service on a VIN-identified asset.
• Commercial model: appointment-checkout for scheduled mobile service (glass/mechanic/detailing/tire); transactional, per-incident for roadside-assistance and locksmith; primary consumer individual.
• Load-bearing stage: S3 Assign / S4 Deliver — the dispatch and the on-site fix. For roadside it collapses to a real-time S2→S4: the call is the job.
• Distinctive stage: VIN→part resolution at S2/S3 (glass SKU, key blank, tire size) and, for auto-glass, a post-install ADAS calibration that gates warranty — the category’s moat overlay, a sibling to HVAC’s EPA 608 that no FSM covers.
• Trust gate: honest diagnosis / no-needless-work; ADAS calibration certified; DOT for towing operations; bonding for locksmith.
• Value-stream-critical assertions: onsite-plus-portal axes derive field dispatch; auto-glass carries the adas tag anchoring its calibration overlay; roadside/locksmith are emergency-reactive (real-time), not scheduled appointments.

6.17 Moving & Logistics (field-dispatch) — moving-company, junk-removal, courier-delivery, last-mile-freight

• Value delivered: a crew and truck travel to load, haul, and deliver goods — household possessions, junk, parcels, or freight.
• Commercial model: transactional per-job for the household side (moving-company, junk-removal); account-based-fees for the B2B side (courier-delivery, last-mile-freight); consumer household vs business.
• Load-bearing stage: S4 Deliver — the move/haul/run itself, bounded by crew-hours × route geography.
• Distinctive stage: route + load planning at S3; the DOT hours-of-service overlay; chain-of-custody for medical/legal courier work.
• Trust gate: careful handling; honest estimate; DOT driver hours; chain-of-custody (medical/legal courier).
• Value-stream-critical assertions: onsite-plus-portal axes derive field dispatch; distinct from wholesale-distribution (which is B2B route delivery of a goods brand’s own stock); the B2B leaves derive customer-accounts.

6.18 Security Services (field-dispatch) — guard-patrol, alarm-cctv-install

• Value delivered: physical protection of people and property — manned/patrol coverage (guard-patrol) and field-installed alarm/CCTV with recurring monitoring (alarm-cctv-install).
• Commercial model: recurring-agreement (guard contracts; monitoring plans); business consumer for guarding, household for residential alarm.
• Load-bearing stage: for guard-patrol, S4 Deliver runs as a real-time post-assignment / patrol-route / incident-response loop — a dispatch variant; for alarm-cctv-install, S3/S4 is the install and S6 Retain carries the recurring-monitoring relationship.
• Distinctive stage: post assignments + patrol routes + incident response (the real-time dispatch variant); the monitoring stream layered on the install.
• Trust gate: licensed officers (PSO); documented incident response; low-voltage licensing (install); credible, never fear-mongering, marketing.
• Value-stream-critical assertions: onsite-plus-portal axes derive field dispatch; guard-patrol’s recurring-agreement makes service-agreements required; install + monitoring compose into one relationship.

6.19 Real Estate & Construction — new-home-builder, custom-home-builder

Added 2026-07-17. This category was seeded (EP-GRID-BUILDER) but had no value-stream profile — the 2026-06-13 changelog’s “87 archetypes” count folded in the 17 Gap-A leaves + 12 Gap-B leaves (= 85) and omitted these two builders. This section closes that gap; the seed is the executable truth (see §5.1).

• Value delivered: the household receives a built home — a production/spec house selected from plans (new-home-builder) or a bespoke house designed and constructed to order (custom-home-builder). Physical goods delivered to a household over a multi-month build.
• Commercial model: milestone/draw-billed project — form=goods, primaryConsumer=household, delivery=physical, billingReadinessMode: prepared-not-prescribed with modules including billing-readiness + projects. Not a slot-booked service and not a shelf-goods sale.
• Load-bearing stage: S2 Capture → S4 Deliver / S5 Settle — capture is plan/design selection; the load-bearing weight is the milestone-billed build project (S4) and its draw schedule (S5). S1 Attract is unusually heavy for the production builder (the model home is the funnel).
• Distinctive stage: each leaf carries a booking item with schedulingDefaults (model-home tour / design consultation) even though the top-level CTA is inquiry — an S1/S3 appointment front-door onto a goods/project business. custom-home-builder additionally runs service-operations for active subcontractor coordination during the build.
• Trust gate: state contractor/home-builder license; new-home warranty obligations; design/architectural sign-off (custom); milestone-draw transparency so the buyer is never over-billed ahead of completed work.
• Value-stream-critical assertions (guarded by archetypes.test.ts “home builder archetypes”): both carry a booking item + schedulingDefaults; form=goods, primaryConsumer=household, delivery=physical; both include billing-readiness + projects with prepared-not-prescribed billing. new-home-builder model homes open 7 days (Sunday hours present); custom-home-builder runs business-hours only (no Sat/Sun tour slots).

6.20 Media Production — film-video-production, post-production-studio, event-production-staging

Added 2026-07-18. This category is project/timeline work that produces a media asset or staged production for a client. It is distinct from asset-rental because the business sells a produced outcome, not the temporary use of equipment, and distinct from live-events-venues because it produces the show rather than selling the ticketed event.

• Value delivered: a produced creative/technical asset or staged production — commercial video, post/VFX delivery, or AV/staging execution.
• Commercial model: inquiry-to-project with milestone/delivery billing; projects and billing-readiness are load-bearing.
• Load-bearing stage: S3 Qualify / S4 Deliver — scope, schedule, crew/artist/suite capacity, dependencies, review rounds, and deadline management determine whether the project succeeds.
• Distinctive stage: waiting-on-client/asset/approval states are not generic notes; they are the project bottleneck and should surface as needs-you quests in the workspace/twin.
• Trust gate: rights/usage, client approval, safety/logistics for event staging, and honest capability promises. Coworker should not blur this into general consulting.
• Value-stream-critical assertions: inquiry forms capture project type, budget/spec, deadline, and brief; seeded booking/discovery items render from schedulingDefaults; workspace/twin derives PIPELINE/timeline posture; milestone/project language survives finance handoff.

6.21 Live Events & Venues — event-venue, tour-promoter, talent-booking-agency

Added 2026-07-18. This category sells or books the show: tickets, venue space, tours, acts, and event dates. It is distinct from media production because physical capacity, dates, holds, guest/fan communication, and settlement are the value-stream spine.

• Value delivered: a guest/fan/client gets access to a live event or talent booking; the operator safely manages capacity, date conflicts, and event readiness.
• Commercial model: ticket/package purchase for event-venue and tour-promoter; inquiry-to-booking for talent-booking-agency; booking sub-flows exist for venue hire and consultations.
• Load-bearing stage: S2 Capture / S3 Qualify & Schedule — the sale or inquiry only works if it respects event date, capacity, space/artist availability, holds, and conflict avoidance.
• Distinctive stage: venue/date/talent conflicts are the core operational risk; the platform must not imply a full ticketing seat-map, payment rail, artist contract, or settlement engine unless those surfaces exist.
• Trust gate: truthful ticket/availability language, accessibility/access needs capture, event safety/staffing posture, and contract/booking boundary clarity.
• Value-stream-critical assertions: “What’s On & Tickets”, “Shows & Tours”, or “Booking Services” vocabulary renders; purchase/inquiry flows issue references; weekend/long-day scheduling appears where seeded; coworker handles double-booking as a decision gate rather than a generic task.

6.22 Warehousing & Fulfilment — third-party-logistics, ecommerce-fulfilment, cold-chain-storage, cross-dock-transload

Added 2026-07-21. The goods-custody category: the operator takes goods it does not own into its facility and is paid to hold and handle them. Gated by the custody-and-fulfilment provisioning axis. Distinct from asset-rental’s self-storage (customer keeps the key; no custody, no handling), from retail-goods’ wholesale-distribution (sells stock it owns), and from moving-and-logistics (custody is transient and in-transit, with no facility inventory of record). Design: docs/superpowers/specs/2026-07-21-warehousing-fulfilment-archetype-design.md.

• Value delivered: a client’s stock is held safely, counted accurately, and despatched correctly and on time — the client’s working capital and their promise to their own customers both sit on the operator’s racks.
• Commercial model: account-based-fees — contract accounts invoiced monthly off a rate card with two meters: storage rent on space held (per pallet/bin per period) plus handling on work done (per receipt, pick, pack, or order), with monthly minimums and accessorials.
• Load-bearing stage: S4c Receive & Store — the custody-only stage inserted between Qualify (the dock appointment) and Deliver (pick/pack/despatch). Custody is won or lost on the inbound: dock-to-stock and inventory accuracy determine whether every downstream pick is possible and correct.
• Distinctive stage: goods come to rest before the outbound work, inverting the rental ordering (where the asset returns after). Stock is strictly segregated per owning client — one client’s inventory must never surface in another’s view.
• Trust gate: goods-in-trust liability and insurance posture, honest count variances (flag a discrepancy rather than absorb it), and per-client data separation. Cold chain adds temperature-record integrity (GDP/GxP).
• Value-stream-critical assertions: storage and handling render as separate revenue lines; the DOCK twin shows dock doors, racking, and pick waves rather than a sales floor; the receive-store stage appears in demand-by-stage; capacity reads as custodial-space (pallet positions/cube), not durable-stock.

Related: freight-brokerage joins moving-and-logistics in the same change — the non-asset movement model (matches shipper to carrier, earns the spread, owns no trucks and takes no custody), so it is deliberately not dispatch-native and declares sales-assisted.

7. Demand–capacity dynamics at the load-bearing stage

The load-bearing stage (Section 6) is not only where the main transaction interface between stakeholders sits — it is also where demand meets finite capacity. That is not a coincidence: a stage is load-bearing precisely because the business lives or dies on its ability to match demand against a scarce resource there. Managing that match — neither starving demand nor paying for idle capacity — is the operator’s hardest recurring decision, and it is where a typical operator most needs the platform’s help.

This section characterises those dynamics per archetype so the platform can later carry adequate functionality to manage them. It is therefore also a requirements input: every “platform lever” named below is a candidate capability the platform must eventually provide (forecasting, advance-booking windows, waitlists, deposits/no-show protection, demand-based pricing, reorder points, seasonal staff flex, utilization dashboards).

7.1 The model: capacity unit × demand signature × two-sided risk

Capacity is not one thing. The scarce resource differs by archetype, and its type dictates which lever works:

Demand has a signature. The shape of the peak dictates how far ahead the operator must plan:

• Weekly cycle — evening/weekend peaks (salon, barber, restaurant, gym classes).
• Annual season — temperature- or daylight-driven (HVAC, landscaping, utility usage).
• Calendar-event spike — fixed dates (florist V-Day/Mother’s Day, pet boarding at Thanksgiving/Christmas, restaurant NYE).
• Fiscal / regulatory cycle — deadline-driven (accounting tax season, corporate-training budget cycles, HOA dues, year-end insurance-benefit use).
• Economic / rate cycle — exogenous (mortgage refi waves; consulting tied to client fiscal planning).
• Unpredictable / emergency — must hold reserve capacity (plumbing burst, vet emergency, property-management lockout, charity disaster appeal).
• Statutory baseline (must-serve) — demand cannot be turned away or fully smoothed (municipality, utility, law enforcement).

The risk is two-sided. This is the crux the operator needs help with, and the cost asymmetry decides the right buffer:

• Under-capacity → demand is turned away: lost revenue, lost customer, reputational damage, and (for must-serve archetypes) statutory failure. Rover data show 39% of pet owners struggle to secure care during peak periods — that is demand walking to a competitor. (MoeGo)
• Over-capacity → resource sits idle or spoils: paid-for staff with no clients, dead stock tying up cash, and — worst — perishables with zero salvage value. A florist who over-orders for Valentine’s is left “not with inventory that can be discounted later, but with organic matter that has zero value within days”; even a 10% overestimate can wipe out the margin, against a baseline 5–10% spoilage rate. (ProfitableVenture) A salon below 70% chair utilization is paying for too much idle time; above 85% it needs to hire. (FinancialModelsLab)

The buffer the operator should hold is a function of that asymmetry: where turn-away is cheap and idle is expensive (perishables, idle labour), run lean and use waitlists; where turn-away is catastrophic and reserve is cheap (emergencies, must-serve), hold slack. The platform’s job is to make that trade-off visible and adjustable, not to leave it to the operator’s gut.

7.2 Per-archetype demand–capacity matrix

Severity note for the audit: a capacity/demand surface (calendar, inventory, roster, lead-time, waitlist) that is missing or wrong on a load-bearing-stage archetype is at least important — it means the platform cannot run that business’s hardest decision.

7.3 What this means for platform functionality (requirements implication)

The matrix collapses to a small set of capabilities the platform must eventually carry to manage demand-vs-capacity for any archetype — parameterised by the capacity-unit type, not hand-built per business:

1. A capacity model per archetype — bind the constrained unit (Section 7.1 type) to the load-bearing stage so the platform knows what is scarce (slot-hours vs hard-cap units vs perishable/durable stock vs throughput).
2. Demand-signature awareness — seasonal/weekly/event/fiscal/rate/emergency tags so forecasting and prompts are tuned to the right cycle, not a generic average.
3. Booking-side levers — advance-booking windows, lead-times, deposits/no-show protection, waitlists, and overbooking-against-no-show — sized by the cost asymmetry (Section 7.1).
4. Inventory-side levers — reorder points / safety stock (durable) and pre-order/cut-off + FIFO (perishable), because over-ordering perishables is the highest-asymmetry loss in the whole set.
5. Workforce-side levers — roster-to-forecast, seasonal/temp flex, emergency-reserve blocking, and utilization-band targets (under = idle cost, over = need to hire).
6. A utilization/occupancy dashboard — the single surface that makes the two-sided risk visible, so the operator manages the trade-off by data rather than by gut.

These are recorded here as the value-stream-derived requirement set; turning them into backlog items is a separate step (they map naturally onto the scheduling, finance/billing, customer-estate, and inventory surfaces the audit already exercises).

Business-analysis acceptance frame. When any of the capabilities above becomes delivery work, the backlog item should carry this minimum evidence:

8. How the architecture feature consumes this

The value streams are not free-text — they bind to substrate the EA surface already holds, so the architecture feature can render them per-archetype without new data:

1. Stage backbone as a value-stream lane. Render the six primary stages + two cross-cuts (Section 2) as a value-stream element for the active archetype, in line with the canonical Value Stream entity and the it4it-is-substrate stance — but labelled as the operational stream (Consume expansion), distinct from the platform’s seven flows.
2. Stage → capability binding from Section 5. Each stage lights up the ActivationProfile.modules, SchedulingDefaults, and BillingPatternProfile that enable it, so the operator sees which platform capability carries which stage of their business.
3. IT4IT seam via PortfolioDecomposition. The It4ItStage[] already attached per PortfolioRole is the join key: the operational stream’s S2–S5 map to the productsAndServicesSold portfolio’s request-to-fulfill (Consume) stage. The EA tool can therefore show both senses of value stream on one canvas without conflating them.
4. ArchiMate export. export_archimate should emit each operational stage as an ArchiMate Value Stream element with serving relationships to the capabilities (modules) from Section 5 — making the operational stream a first-class, exportable architecture object, not a doc-only diagram.
5. Banking already shows the pattern. The BIAN seededServiceCategories (Loans and Deposits, Relationship Management, Compliance) are exactly an operational-value-stream decomposition anchored to an industry standard — the model to generalise to the other 50 archetypes.
6. Demand–capacity overlay (Section 7). Render the constrained capacity unit and demand signature on the load-bearing stage so the EA canvas shows not just which stage carries the business but where it is capacity-constrained — the join point to future capacity-management capabilities.

8.7 EA usability presentation contract

The architecture feature has two audiences: operators who need to run the business, and architects/admins who need to understand the substrate. The same model should serve both without exposing the wrong level first.

Do not make the first viewport a wall of EA terminology. The load-bearing stage, trust gate, and next operational risk are the first-viewport signals; standards mapping is a drill-down.

8.8 Decision substrate — feeds WWWD (business context), not WWMD (platform)

This artefact is business-context substrate, and the platform keeps two decision perspectives strictly separate by context. Routing the value-stream architecture to the wrong one would have a coworker reason about a salon using the platform’s own build-prioritization stance — exactly the conflation to avoid.

How it feeds WWWD. The per-archetype value-stream architecture gives a new install a starting WWWD perspective grounded in how its kind of business actually works — before the org has accumulated its own decision history. A coworker asking “what would we do here?” for a veterinary clinic should land on: encounter-based, load-bearing stage is Deliver, capacity is vet slot-hours against seasonal+emergency demand, trust gate forbids clinical advice — and weight its recommendation accordingly. As the org accumulates its own decisions, its WWWD overlay compounds on top of this archetype-seeded baseline (mirroring how the founder kernel notes an org evolves “from what would Mark do toward what would we do”).

The separation is the rule: business-of-the-customer decisions → WWWD (seeded by this artefact); portal/platform/build/architecture decisions → WWMD. A coworker must select the perspective by context, never blend them.

8.9 Provider suitability consumes the value-stream lens

AI provider policy composes onto this projection without creating a second vertical or process taxonomy. The canonical StorefrontConfig archetype and a real OperationalValueStreamStageKey provide conservative workload defaults when an activity does not already carry a governed data profile. For example, attract defaults to public marketing; settle defaults to payments/finance; healthcare delivery, banking delivery, education delivery, and public-sector delivery resolve to their bounded regulated workload classes.

The activity contract may carry logical governed asset/field references, processing purpose, and workload hints. Those references identify the work but do not classify or authorize it: the govern/data profile and PDP remain authoritative and override every archetype default. Unknown or conflicting high-risk context fails to review/deny. Occupation is a recommendation-focus lens only and cannot widen RBAC, coworker grants, tool authority, or provider eligibility.

This preserves one route-selection path: the work-context adapter produces workload profiles for the existing provider-suitability compiler, which produces hard constraints for the existing V2 router. Cost, quality, health, and capacity rank only inside that eligible set.

9. How the audit consumes this (and the back-reference)

• Before a run: read the archetype’s Section 6 profile to know its load-bearing stage(s) and trust gate. These set where to scrutinise hardest and how to grade severity (Section 4 severity-derivation rule).
• During a run: when logging a finding, name the value-stream stage it breaks in the OBSERVATION/EXPECTED, and let the load-bearing status drive severity. “Pet fields missing on vet booking” → breaks S2→S4 handoff of an encounter-based, S4-load-bearing archetype → critical, with the rationale stated rather than asserted.

• After a run: the post-audit BI consolidation (test plan Section 10) can group findings by value-stream stage across archetypes — e.g. “S3 Schedule defects” or “Trust-gate disclosure gaps” — which is a more actionable dedup axis than per-archetype symptoms.

• Capacity-aware testing: read the archetype’s Section 7 row before driving Phase P/B/G. A booking calendar that ignores real availability, an inventory surface with no reorder concept, or a finance flow blind to recurring/seasonal revenue is a defect against the load-bearing demand–capacity decision, not a cosmetic gap — grade it accordingly.

The archetype audit plan carries a back-reference to this document in its Related line and a pointer in its Section 1 so any execution thread reaches the value-stream rationale before driving phases.

10. Recognized gaps — value-stream patterns not yet covered by a seeded archetype

This section records value-stream patterns beyond the original six-stage backbone. One — the rental / shared-asset loop — was identified here as a gap and has since been built upstream; it is retained as the canonical description of that pattern (now realized) plus the platform-capability work that remains.

10.1 The rental / shared-asset utilization loop (now modelled upstream — asset-rental + agricultural-cooperative)

Businesses: equipment & tool rental, vehicle/trailer rental, party & event rental (tents, chairs, AV), film/production equipment rental, self-storage, and the agricultural co-op that shares machinery among member-farmers.

Substrate check (re-verified 2026-07-18 against origin/main): these are now seeded. The asset-rental category carries equipment-rental, self-storage, and production-equipment-rental; the cooperative’s agricultural/shared-machinery sub-type was promoted to a dedicated agricultural-cooperative leaf (category nonprofit-community, member-owned) whose items reserve shared machinery equitably among members. A rental value exists in the CtaType enum, and rental-fleet / rental-agreements / asset-pool capability types plus a rental/shared-asset entitlement model are in types.ts.

Why it’s a genuinely new pattern — not just a missing name. Every commercial model in Section 3 assumes the offered thing either leaves (sale, donation) or is consumed in a slot (appointment, encounter). A rental asset does neither: it is reserved → handed out → used for a period → returned → inspected → re-pooled. That utilization loop is a value-stream shape the current six-stage backbone only partially fits:

  S1 Attract → S2 Reserve a specific asset for a window → S3 Agreement/Deposit/ID
            → S4 Hand-out & Use period → S4b RETURN & INSPECT → S5 Settle (+ damage/late fees) → S6 Re-pool & Retain

The new element is S4b Return & Inspect and the re-pool — there is no “return” stage anywhere in the sale/booking/donation streams.

The capacity dynamic it adds (refines Section 7.1). The capacity unit is neither a perishable nor a static hard cap — it is a reusable pooled asset, and its KPIs are asset-utilization %, turnaround time between rentals, reservation conflicts/overbooking, deposit & damage exposure, and overdue returns. The demand signature is the sharpest synchronized-contention case in the whole set:

• Ag-equipment co-op: every member-farmer needs the combine/baler in the same harvest window — peak demand is not just seasonal, it is simultaneous against a shared pool that cannot scale for one fortnight a year.
• Equipment/vehicle/party rental: month-end and weekend moving trucks; wedding/graduation-season event kit; spring/summer tool demand.
• Self-storage: a physical hard cap (like kennels) rented on a subscription/occupancy basis — its KPI is occupancy %, its peak is the moving season, and its over-capacity failure is the empty unit.

The co-op wrinkle the commercial renter doesn’t have: when a shared member-owned pool cannot meet simultaneous demand, it must ration equitably among member-owners (fair scheduling / allocation), not simply clear the queue by price. That is a member-governance capability (allocation fairness) layered on the rental loop — exactly the seam the existing member-owned GovernanceModel exists to gate.

What is built vs. what remains. Built (2026-06-12): the three archetype leaves, the rental CTA, the reservation-with-return form fields (pickup/return dates, unit size, waitlist), and the rental-fleet/rental-agreements/asset-pool capability types. Remaining is the cross-archetype asset-pool capacity engine — the running surfaces that make the S4b Return & Inspect loop and the reusable-pooled-asset KPIs real: reservation-conflict/overbooking checks, turnaround/utilization tracking, deposit & damage exposure, overdue-return handling, and (for the co-op) the equitable-allocation rationing layer over conflicting member reservations. That engine is the rental-family instance of this design’s deferred capacity-management requirement set (Section 7.3 / the implementation design §7.3, §10) — not a per-archetype template but a first-class platform capability.

Disposition: archetypes — done (equipment-rental, self-storage, production-equipment-rental, agricultural-cooperative). The rental/shared-asset value-stream pattern and its reusable-pooled-asset capacity unit are now a recognized part of the model (this section is their canonical description). The asset-pool capacity engine is tracked as capacity-management work, not new-archetype work.

10.2 The field-dispatch (mobile-resource-to-customer) loop (now modelled — Gap A leaves + Gap B categories, 2026-06-13)

Businesses: any business where a mobile resource travels to the customer’s site, asset, or person to perform the work, rather than the customer coming to a premises. This recurs across the catalog rather than living in one category:

• Folded into existing categories (Gap A leaves): hvac-contractor, pest-control, appliance-repair, pool-spa-service, pressure-washing, roofing-gutters (trades); home-health-care, mobile-phlebotomy, dme-delivery (healthcare); mobile-pet-grooming, mobile-vet (pet); field-inspection, land-surveying, process-serving-notary (professional); mobile-beauty (beauty); meal-delivery-program (nonprofit); furniture-delivery-install (retail).
• New dispatch-native categories (Gap B): automotive-services (§6.16), moving-and-logistics (§6.17), security-services (§6.18).

Why it’s a recognized pattern — not just a set of leaves. In every commercial model in Section 3 the Deliver (S4) stage happens at the operator’s premises or in a booked slot there. In field dispatch S4 happens at the customer’s location, which inserts coordination stages a premises-based stream never has — assign (skill × proximity × availability), en-route (on-my-way + ETA), and on-site capture. It is derived, not flagged: applicability is a pure function of the operating-model axes —

needsFieldDispatch(axes) := form="services" AND delivery∈{physical,hybrid}
                            AND service performed at the customer's location or on the customer's asset

read from consumptionChannel: onsite-plus-portal (and episode-of-care provisioning for in-home care). The loop:

  S1 Attract → S2 Intake/Triage → S3 Schedule & Assign(skill×proximity×availability)
            → Confirm → En-route (on-my-way + ETA) → S4 On-site (capture / compliance log)
            → Close → S5 Settle (job → invoice → payment)

The capacity dynamic (refines §7.1). The capacity unit is mobile labour + route capacity — technician/crew/officer-hours × drive-time geography — already in the §7.1 taxonomy. Demand signatures vary: emergency-reactive (HVAC no-heat, roadside, lockout), seasonal (moving, pest), steady (guard coverage, monitoring).

Compliance overlays as job by-products — the moat. Each vertical attaches a regulated artifact captured at job close: EPA 608 (HVAC), ADAS calibration (auto-glass), pesticide-applicator logs (pest), HIPAA/clinical notes (home-health, phlebotomy, medical courier), DOT hours (moving, towing), PSO / low-voltage licensing (security). This is a pluggable overlay framework, not per-archetype code — and no field-service-management product in the market covers any of these.

Disposition: archetypes — done (the 17 Gap-A leaves + 3 Gap-B categories above; all carry the onsite-plus-portal axes and compose under service-operations until the dispatch module ships). The horizontal Field Dispatch capability — the dispatch board (map-dispatch visual pattern), the dispatcher coworker, the skill/proximity/value-aware assignment engine, on-my-way/ETA, and the compliance-overlay framework — is built by a parallel effort and derives from these axes via needsFieldDispatch(); it is tracked as capability work, not new-archetype work. Source: the 2026-06-13 Field Dispatch capability design and its companion archetype gap analysis.

11. Changelog

• 2026-07-18 — Re-grounded the active text against the current source catalog: 95 archetypes / 21 categories. Added §6.20 media-production and §6.21 live-events-venues, moved medical-practice/optician under healthcare-wellness, corrected fitness/education/nonprofit category headings, and added production-equipment-rental to the rental/shared-asset loop.
• 2026-07-17 — Closed the real-estate-construction coverage gap: added §6.19 (new-home-builder, custom-home-builder) and a §7.2 demand–capacity row for the builders + a field-dispatch capacity row. These two builders (EP-GRID-BUILDER) were seeded but never given a value-stream profile — the 2026-06-13 “87 archetypes” count folded in the 17 Gap-A + 12 Gap-B leaves (= 85) and silently omitted them. Inventory re-grounded against origin/main packages/storefront-templates/src/archetypes/ (enumerated ALL_ARCHETYPES, cross-checked archetypes.test.ts): 87 archetypes / 19 categories confirmed (real-estate-construction is the 19th category, 2 leaves). Surfaced by the archetype audit plan 87/19 re-grounding (BI-186FFCA7, EP-ARCH-8D4F2A).
• 2026-06-13 — Folded the field-dispatch archetypes from the 2026-06-13 gap analysis into the catalog: 17 Gap-A leaves across 7 existing categories (trades, healthcare, pet, professional, beauty, nonprofit, retail) and 3 new dispatch-native categories — automotive-services (§6.16), moving-and-logistics (§6.17), security-services (§6.18). Added §10.2 recognizing the field-dispatch (mobile-resource-to-customer) loop as a value-stream pattern that spans categories and is derived from the operating-model axes (onsite-plus-portal). Seed count is now 87 archetypes across 19 categories. Each leaf carries the axes that let the forthcoming horizontal Field Dispatch capability derive dispatch via needsFieldDispatch(); the capability itself is a parallel effort.
• 2026-06-12 — Added Implemented by link to the platform implementation design (2026-06-12-value-stream-architecture-platform-design.md) and the WWWD consumer/§8.8 reference. Corrected §10.1: the rental / shared-asset gap was built upstream (asset-rental category + equipment-rental/self-storage/agricultural-cooperative, rental CTA, asset-pool capability types; seed now 56) — flipped from “not modelled” to “now modelled,” retaining the pattern as canonical and narrowing the remaining work to the asset-pool capacity engine. (Sweep-main caught a worktree-stale gap claim.)
• 2026-06-12 — Enterprise architecture / usability / business-analysis review: clarified decision authority, added reader contract, corrected the standards grounding so ArchiMate and Business Architecture Guild usage are aligned rather than conflated, added architecture/usability invariants, added BA acceptance evidence for demand-capacity capabilities, and split EA consumption into operator, evidence, and architecture/export presentation views.
• 2026-06-11 — Initial draft. Derived from archetype-audit-plan.md (53 archetypes, 14 categories), the archetype seed (packages/storefront-templates/src/archetypes/), and the operating-model substrate (types.ts). Defined the universal six-stage operational value stream, the commercial-model variant table, the stage→surface→phase bridge, the substrate binding, and per-category profiles for all 53 archetypes.
• 2026-06-11 — Added Section 7 (Demand–capacity dynamics at the load-bearing stage): capacity-unit taxonomy, demand-signature taxonomy, two-sided over/under-capacity risk model, a per-archetype demand–capacity matrix for all 53 archetypes (researched seasonality/capacity grounding cited inline), and the derived platform-functionality requirement set. Renumbered subsequent sections (8 architecture, 9 audit, changelog).
• 2026-06-11 — Added the WWWD decision-substrate consumer (§0 item 4) and Section 8.8 (WWWD-vs-WWMD context separation): this artefact is business-context substrate that seeds the org’s “What Would We Do” perspective; WWMD (“What Would Mark Do”) stays scoped to platform/portal/build/architecture decisions. Decisions must select the perspective by context, never blend them.
• 2026-06-11 — Added Section 10 (Recognized gaps): documented the rental / shared-asset utilization loop — equipment/vehicle/party rental, self-storage, and the agricultural shared-machinery co-op — as a value-stream + capacity pattern none of the 8 commercial models expresses (new S4b Return & Inspect stage; reusable-pooled-asset capacity unit; synchronized-contention demand; co-op equitable-allocation wrinkle). Verified against the seed that no such leaf exists and that cooperative is modelled as a consumer/membership co-op. Changelog renumbered to 11.