Platform architecture
How M2 Visibility separates the public experience, authenticated application, Enterprise control planes, operational data, integrations and audit evidence.
How to interpret this document
This content describes technical and methodological behavior that is implemented or explicitly planned in the product. When a control depends on configuration, a provider, a secret, a contract or legal approval, that dependency must remain visible.
Core layers
The architecture separates the public website, authenticated application, backend functions, business entities, Enterprise policies and external connectors. The goal is to reduce coupling between experience, authorization and operations.
Domains
m2ia.app represents M2.IA as the parent company. visibility.m2ia.app represents M2 Visibility, documentation, Trust Center and the authenticated application. Hostname separation also organizes canonical URLs, sitemaps and brand experience.
Control planes
Entitlements, billing, identity, audit, API, Integration Hub, readiness and launch control operate as distinct control planes instead of concentrating unrestricted authority in one administrative surface.
Operational data
MeasurementRun, jobs, responses, metrics, recommendations and snapshots persist the evidence needed for analysis and operations. Derived state should be reconstructible from canonical sources whenever possible.
Service role
Operations that require elevated authority are performed through specific backend functions. An admin browser session does not provide generic service-role power.
Fail closed
When a secret, provider, entitlement or tenant-safety requirement is unavailable, the expected behavior is to block or explicitly degrade the capability rather than simulate availability.