Arquitetura da plataforma
Como M2 Visibility separa experiência pública, aplicação autenticada, control planes Enterprise, dados operacionais, integrações e evidências de auditoria.
Como interpretar este documento
Este conteúdo descreve o comportamento técnico e metodológico implementado ou explicitamente planejado no produto. Quando um controle depende de configuração, provider, secret, contrato ou aprovação jurídica, essa dependência deve permanecer visível.
Camadas principais
A arquitetura separa website público, aplicação autenticada, funções backend, entidades de negócio, políticas Enterprise e conectores externos. O objetivo é reduzir acoplamento entre experiência, autorização e operação.
Domínios
m2ia.app representa a empresa M2.IA. visibility.m2ia.app representa o produto M2 Visibility, documentação, Trust Center e aplicação autenticada. A separação de hostname também organiza canonical, sitemap e experiência de marca.
Control planes
Entitlements, billing, identity, audit, API, Integration Hub, readiness e launch control operam como control planes distintos, evitando que uma única tela administrativa concentre autoridade irrestrita.
Dados operacionais
MeasurementRun, jobs, respostas, métricas, recomendações e snapshots persistem a evidência necessária para análise e operação. Estados derivados devem ser reconstruíveis a partir de fontes canônicas sempre que possível.
Service role
Operações que exigem autoridade elevada são executadas por funções backend específicas. A existência de uma sessão admin no navegador não concede service role genérico.
Fail closed
Quando um secret, provider, entitlement ou requisito de tenant safety está ausente, o comportamento esperado é bloquear ou degradar explicitamente a capacidade em vez de simular disponibilidade.