Tenant Capability Overlays
Tenants are configured product environments, not just generic users of Mobilis Core.
Each tenant can enable a different subset of Mobilis capabilities, use different services, apply its own workflow rules, and publish its own website content, FAQs, docs, and Flow Studio emulator scenarios.
Layer Model
Examples
| Tenant | Enabled capabilities | Tenant-specific layer |
|---|---|---|
| FiestaGenius | Event submission, moderation, publishing, billing | broad event categories, public site, paid upsells, web and WhatsApp channels |
| Mi Gente DMV | Event submission, distribution hub, marketplace app | Latin dance categories, Mi Gente copy, GoLatinDance bridge, Mi Gente FAQs |
| RugbyMonkey | Event submission, community listings | rugby categories, team/community moderation, RugbyMonkey website content |
| GoLatinDance Operations | Source ingest, dedupe, candidate review, publishing packages | source trust rules, operator workflows, restricted admin docs |
Override Order
Mobilis defaults
-> product capability defaults
-> tenant defaults
-> tenant market/region/community overrides
-> environment-specific release notes or warnings
Overrides should be explicit and traceable. Tenant differences should be expressed through configuration, content, docs, scenario packs, and adapters instead of one-off forks of product logic.
Prototype Workspace
Tenant experiments live in the owning tenant repo under root-level prototypes/.
Each prototype needs a README, handoff prompt, merge map, and experiment.yaml. The prototype README and metadata must use a canonical title/repo slug that includes the tenant or system name:
prototype-<tenant-or-system>-<purpose>
Example:
prototype-migente-staticinstructorsandstudiosdirectory
Accepted prototype output must be promoted explicitly into tenant website/content, tenant data, tenant docs, tenant scenarios, Flow Studio, product capability, or Mobilis Core layers. Anything not promoted needs an archive/delete/abandon decision.
Shared Config Contract
The shared config contract is the handoff point between core defaults, product defaults, tenant overrides, docs, and Flow Studio.
Every active tenant should have a contract packet that includes tenant metadata, capability profiles, brand tokens, website content, FAQs, scenario packs, and launch references. Flow Studio should generate tenant emulator views from that packet instead of hardcoded tenant screens.
Product Boundary Rule
Tenants configure product capabilities; they do not redefine them. FiestaGenius, Mi Gente DMV, RugbyMonkey, and GoLatinDance Operations can become standalone tenant product surfaces while still consuming reusable Mobilis product capabilities.
| Tenant surface | Uses reusable capability | Tenant-owned layer |
|---|---|---|
| FiestaGenius | Event Submission Platform | FiestaGenius brand, website, event categories, FAQ, support copy, launch evidence |
| Mi Gente DMV Submission Tool | Event Submission Platform, Marketplace App Platform | Latin dance rules, Mi Gente app/site copy, distribution policy, tenant scenarios |
| RugbyMonkey | Event Submission Platform | rugby categories, RugbyMonkey website content, community moderation copy |
| GoLatinDance Operations | Source Ingest Platform | source trust policy, operator runbooks, connector evidence, GLD-specific scenarios |
Launch Project Requirement
Every tenant launch should have a dedicated GitHub Project or project view named:
Tenant Launch: <Tenant Name> - <Capability or Release>
The project should track:
- tenant capability profile
- website/content pack
- canonical domain, hyperlocal domain, short-link domain, QR/deep-link, and redirect analytics policy
- brand/design tokens
- public FAQs and help docs
- operator/admin docs
- Flow Studio tenant scenario pack
- service and integration setup
- permission and visibility review
- launch smoke tests
- release evidence
- post-launch feedback
Runbook And Evidence Requirement
Every launch project should link a launch runbook and release evidence file before launch gates are marked verified. The runbook explains what to do; the evidence file proves what was checked.
Unified Schema NFR
Tenant capability changes that affect public pages, domains, short links, QR/deep links, imports, payments, moderation, communications, or provider integrations must link to the unified schema control system before launch-enabling implementation.
Required controls:
- public pages read approved projections/views, never raw imports or private evidence
- dormant contracts may exist for payments, wallets, affiliates, communications, subscriptions, gamification, access tiers, short links, QR assets, redirect analytics, and abuse controls, but do not launch public APIs, public redirect routing, live provider calls, or money movement by themselves
- short-link domains such as
migente.dancestay tenant/domain scoped, noindex/redirect-first, privacy-preserving for analytics, and unable to override canonical SEO routes unless a launch-gated tenant publication policy explicitly enables that behavior - every public, provider, payment, moderation, communications, data-access, or tenant-surface request must declare schema, NFR, docs, Flow Studio, launch gate, and backlog impact