Enterprise controls
Map Ethen’s current identity, governance, security, billing, and observability surfaces to their unresolved enterprise-control boundaries.
Enterprise controls
Enterprise control in Ethen is currently a collection of product surfaces and implementation boundaries rather than a complete, centrally administered enterprise-control plane. Identity can be configured, projects have a route family, policies and approvals are visible, audit and observability surfaces exist, and usage and billing concepts are represented. Several of those capabilities remain optional, sample based, fixture backed, demo-only, or externally blocked.
Use this overview to decide which control area to review next. The manifest’s generally available maturity remains under conflict review, and no compliance certification or complete enterprise feature set is asserted.
Enterprise scope
The current enterprise scope includes identity entry points, project-oriented navigation, configuration, policy and approval concepts, audit-oriented views, usage surfaces, billing readiness types, and observability dashboards.
These surfaces are not proof of a unified organization hierarchy, centralized authorization, complete tenant isolation, production billing, or comprehensive telemetry. An enterprise review should map each requirement to the route, server check, store, operator, and external dependency that actually implements it.
The most important current-state labels are optional, Private Alpha, Sample, Fixture, Demo-only, Bridged, Unavailable, and Unverified. They indicate where a route can support evaluation without supporting a production control objective.
Control-readiness map
An enterprise review should classify each capability by both function and readiness.
| Capability | Current evidence | Enterprise question still open |
|---|---|---|
| Identity entry | Optional Clerk integration and sign-in routes | Which routes are protected and how identities map to resources |
| Projects | Project route family and product-specific subroutes | Durable ownership, membership, isolation, archival, and deletion |
| Policy and approval | Product-specific decisions and approval surfaces | Central coverage, durable decisions, reviewer roles, and exceptions |
| Audit | Private Alpha sample route and fixture entries | Production ingestion, completeness, retention, access, and export |
| Billing | Demo-only readiness types and route | Payment infrastructure, products, invoices, metering, and reconciliation |
| Observability | Run and receipt summaries with honesty labels | Complete traces, TTFT, fallback, cost trust, and runtime coverage |
| Support and status | Public routes | Operating process, severity model, cadence, and commitments |
This map is more useful than a single “enterprise ready” label because it shows which control can be evaluated and which one still depends on architecture, infrastructure, or policy.
A control can move from visible to operational only after its backend, ownership, enforcement, and evidence are verified. Preserve that transition in documentation rather than letting the manifest maturity stand in for implementation proof.
Identity and access
Clerk can be enabled conditionally at the root, and sign-in and sign-up routes exist. Universal route protection, complete Clerk-to-Supabase identity bridging, enterprise federation, automatic provisioning, and a durable organization role model are not established.
Administrators should review identity at the protected resource. Confirm how the server obtains the user, how project ownership is derived, and which backend rules prevent cross-project access. A navigation item or authenticated page is not sufficient evidence.
Continue to Organization and user administration for the current administration boundaries.
Identity boundary review
For each sensitive enterprise route, identify the authentication mechanism, server-side authorization check, resource owner, and backing-store rule. Optional root authentication is only the first line in that chain.
A deployment should also decide how service identities and API keys fit beside human users. A Gateway key can invoke model routes without representing a browser session. A Supabase service role can access data outside normal user policies. A provider credential grants access to an external account. Enterprise administration must inventory all of them rather than treating user sign-in as the complete access model.
The unresolved organization hierarchy means account and project ownership should not be generalized across the platform.
Governance
Governance surfaces include policies, approvals, project settings, and security documentation. Product-specific decision states can allow, deny, block, or require approval. Their enforcement and persistence vary by subsystem.
A complete enterprise governance model would also need approved roles, resource ownership, exception handling, access review, durable evidence, and a clear separation between requesters and approvers. Those capabilities remain incomplete.
Use governance pages to understand current concepts, not to infer certification or organization-wide control inheritance.
Governance decision points
Enterprise governance becomes concrete at changes that affect access, data destinations, cost, code, or operational risk. Examples include adding a provider credential, changing a policy, approving a high-impact proposal, granting project access, or enabling a new environment.
For each decision, document the requester, authorized reviewer, resource, expected side effect, evidence, and verification after the change. Current product surfaces can support parts of that model, but no unified change-governance workflow is proven.
Avoid using the audit sample route as the only record of an enterprise decision. Where persistence is incomplete, retain an approved external record and label it as such.
Security controls
Current security-oriented controls include configuration validation, server-only boundaries, safer error patterns, optional authentication, product-specific credential handling, CSP configuration, and read-only Sentinel review.
Universal encryption at rest, customer-managed encryption keys, complete RLS, fixed retention, production audit export, and formal incident SLAs are not verified. Customers should evaluate the deployed infrastructure and provider accounts alongside application behavior.
The Security and Governance section owns the detailed boundaries for data, credentials, policies, approvals, and evidence.
What can be assessed now
Security reviewers can assess configuration detection, public-versus-server environment separation, root identity configuration, product-specific policy and approval states, safer error handling, read-only Sentinel boundaries, and honesty labels on sample or fixture data.
They cannot conclude that every route is authenticated, every store is protected by complete RLS, every credential is encrypted and audited, or every event reaches a durable audit log. Those questions require deployment tests and approved infrastructure.
No certification, formal third-party audit, or compliance attestation follows from these controls.
Operations
Operational surfaces cover usage, logs, runs, evaluations, observability, platform status, help, and contact. Observability can combine bridged, fixture, and unavailable data; billing is explicitly demo-only; public support and status routes carry no documented SLA.
Use the data-honesty state before relying on a metric. Cost estimates are not invoices, fixture errors are not production incidents, and a status page does not create an uptime commitment.
Operational readiness also depends on production Supabase, durable storage, metering, audit ingestion, support processes, and release procedures that remain external blockers.
Operating dependencies
Production operations require more than the visible dashboards. Durable project, usage, audit, and evaluation records depend on configured stores. Budget checks depend on trusted and timely usage writes. Support and incident handling depend on approved people and processes. Release notes depend on an authoritative change record.
Treat each dependency as an operating requirement with an owner. If Supabase, provider accounts, or observability emitters are not configured, the affected control should be labeled setup required or unavailable rather than inferred from the route.
This dependency model also helps prioritize work: identity and ownership should be resolved before adding broader administration, and trusted metering should precede live billing.
Where to begin
Start with the control objective rather than the interface.
- For identity, membership, roles, and access review, read Organization and user administration.
- For project ownership and environment boundaries, read Projects, environments, and resource boundaries.
- For costs and demo-only billing, read Usage, billing, and cost controls.
- For telemetry honesty, read Observability, traces, errors, and evaluations.
- For public help and status routes, use Status, support, release notes, and troubleshooting index.
Keep every page in draft review until its required control and maturity flags are resolved.
Prioritization
Resolve controls in dependency order. Establish trusted identity and resource ownership before expanding roles or approvals. Configure durable storage and access rules before relying on audit or usage history. Establish trusted metering and customer ownership before implementing billing. Define operating owners before making status or support commitments.
This order reduces the chance that a polished interface hides a missing foundational boundary.
Use the remaining review flags as an implementation checklist, not as a substitute for testing. A flag is resolved only when the deployed control and its evidence are verified.