Domain-Based Feature Activation

A declarative, applied-once configuration list — not a runtime feature-flag engine

1. Requirements

1.1 Functional requirements

At setup time, let an implementer tag a legal entity with a business domain (manufacturing, retail, distribution, or services) reflecting the kind of organization it is.
For each business domain, ship a small, fixed set of presentation adjustments appropriate to that kind of business: navigation shortcuts, a field-visibility rule, a couple of setting values to pre-apply, and a default self-service portal role.
Surface a short onboarding checklist of suggested next actions, filtered so only items relevant to the tagged domain are shown.

1.2 Non-functional requirements

Simplicity over configurability: each domain’s adjustments are a plain, static data structure, not a scripted rule engine — nothing about it can be tuned without editing that structure directly.
No new record types: the business-domain tag rides an existing, general-purpose field on the legal entity record rather than a dedicated master with its own validation.

1.3 Constraints

Exactly four business domains are declared in this codebase. Nothing prevents a fifth being added as a fifth static declaration, but nothing in this codebase parses or applies such a declaration automatically (§ 3.2).
The business-domain tag is a free-text field, not a constrained choice list validated against the four declared domains — a typo or an arbitrary string is stored without complaint.

2. High-Level Design

2.2 What actually happens, end to end

A short annotated walkthrough, because most of these steps are one-shot:

At company creation, whatever value the implementer chose is written verbatim into the legal entity’s Business Domain Tag — the only place in this codebase that touches the tag as part of setup.
Four Domain Declarations exist as plain, static data structures, one per business domain, each listing a handful of navigation shortcuts, at most one field-visibility rule, one or two default setting values, and a default portal role. None is more than 25 lines; none has executable logic beyond the literal list.
Nothing in this codebase reads or applies a Domain Declaration. No dispatch table anywhere in this tree maps a domain name to its declaration file, and no code path walks one of the four files’ shortcut list, visibility rule, or setting values. If that application step exists, it runs entirely in platform code this codebase does not contain — asserted here only as far as the declared input is concerned, not what consumes it.
The tag is read again in exactly one place with an ongoing, not one-shot, effect inside this codebase: an onboarding checklist of suggested next actions is filtered, on every call, against the tag’s current value.
The tag is also read once more, for reporting only, alongside a record-count-based “activation level,” for outbound site-health telemetry — this consumer gates nothing.
Two navigation entries, out of dozens in this codebase, carry a static domain-restriction marker naming one of the four domains each; every other entry leaves it blank. What enforces that marker is not resolvable from this codebase.

Business Domain Tag A single plain-text field on the legal entity record, filled once at company creation from whatever value the setup flow supplies. Never validated against the four declared domain names; never re-derived; changing it later is a manual edit like any other field.

Domain Declaration (one of four static files) A literal data structure, not a record type or a database row: a short list of navigation-shortcut names, zero or more field-visibility rules, zero or more setting values to pre-apply, and one default portal role. No shared schema validates these — each file simply follows the same shape as the other three.

Onboarding Activation Checklist Not a stored record — a function that, given the legal entity’s current tag value and a fixed in-code list of candidate suggestions (each with an optional tuple of applicable domains and a target count), returns the suggestions whose domain tuple includes the current tag (or has none, meaning “always applicable”) and whose live record count hasn’t yet reached the target.

3.2 What could not be verified here

The largest open question this document deliberately leaves unresolved is what applies a Domain Declaration’s shortcut list, visibility rule, and setting values. No file in this codebase imports any of the four declaration files, and no dispatch structure maps a domain name to one of them. A platform-level mechanism that discovers and applies a declaration by naming convention is plausible, but unverified, so it is not asserted here — a claim that cannot be checked against a file actually read should be dropped rather than guessed. What is verified: the only components that read the tag and do something with it on an ongoing basis are the onboarding checklist and the telemetry reporter; everything else touching “domain” either writes the tag once at setup, or declares static data nothing in this tree consumes.

3.3 Error handling

There is none to speak of. The tag accepts any text; the setup write path does not validate it against the four declared domains; the checklist filter degrades gracefully to “always applicable” for any suggestion without a domain restriction, and to “no matching suggestions” for a tag value that matches none of the four (including a typo, or no domain at all). Nothing raises, warns, or logs on a mismatch anywhere in this codebase.

4. Scale and Reliability

This mechanism has essentially no runtime scale profile, because — as far as this codebase demonstrates — there is almost nothing running. The tag write happens once, at company creation. The only repeated, ongoing consumer is the onboarding checklist, a handful of in-memory comparisons against a dozen or so candidate suggestions with no query cost worth discussing. If the unverified declaration-application step in § 3.2 does run in platform code, its cost is likewise one-time by construction — the four declarations are small and static. The narrowest reliability gap worth naming is the free-text tag itself: never validated against the four declared names, so a legal entity can end up with a value that matches none of them, silently degrading the checklist to “nothing applies” with no error surfaced.

5. Trade-off Analysis

Decision	Trade-off
Domain as a free-text field rather than a constrained choice list	Trivial to extend with a new domain name at setup time; but a typo or drift produces silent, unreported mismatches everywhere the tag is read, instead of a validation error at the point of entry.
Static, literal data structures for each domain’s adjustments rather than a rule engine	Easy to read and audit — a domain’s whole behavior fits in well under thirty lines; but there is no way to compose or extend one domain’s behavior without editing its file, and no way to add a fifth without also updating whatever platform-side mechanism (unverified here) discovers the four.
A one-time setup application (as far as verifiable) rather than a live, continuously-enforced feature gate	Nothing to keep synchronized at runtime; but changing a legal entity’s declared domain later does not re-apply anything, so the presentation adjustments and the tag can drift apart with no reconciliation mechanism.
One narrow live exception (the onboarding checklist) inside an otherwise one-shot mechanism	Keeps onboarding guidance current without a re-setup step; but it is the only part of this mechanism that behaves like a feature flag, making “domain-based activation” a partially misleading label for the mechanism as a whole.

6. What to Revisit as the System Grows

This is not a feature-activation framework and should not be described as one without the caveats above. A genuine one would need, at minimum: a constrained (not free-text) domain value; a discoverable, in-code mapping from domain name to the behavior it turns on or off; and continuous enforcement rather than a one-time application — none of the three exists verifiably in this codebase today.
Validate the tag against the four declared names at write time, or make it a proper choice field, so a mismatch is caught at setup rather than silently degrading the one live consumer that reads it.
Make the declaration-application step (§ 3.2) discoverable from this codebase if it is meant to keep working as domains are added — right now, adding a fifth declaration would require knowledge of a mechanism this codebase gives no evidence of.
Decide whether domain should ever be re-appliable. Nothing here re-runs the presentation adjustments if a legal entity’s declared domain changes after setup; whether that is acceptable depends on how much weight the business places on the tag beyond onboarding guidance.