The Platform-and-Modules Mental Model

Before you configure a single setting, get the mental model right: EchoFoundry is one core platform, and every product you touch (EchoAgents, EchoAI, EchoCouncil, and the rest) is an independently subscribable module built on top of it. Confusing "platform" and "module" is the single most common source of operator mistakes in the first month.

One core, many systems

The core owns the things every module needs and none of them should rebuild: identity and SSO, capability-based authorization, tenant isolation, shared services (files, approvals, notifications, automation, audit), and governed AI access. A module (EchoAgents, EchoAI, EchoMail, whichever ones your org has subscribed to) sits on top of that core and inherits all of it automatically. It does not reimplement login, it does not reimplement permissions, and it does not reimplement audit logging. It uses the core's.

This is why the platform strapline is "one core, many systems, momentum builds": the momentum comes from not rebuilding plumbing every time you adopt a new module.

What "independently subscribable" actually means for you as an operator

Your organization can subscribe to exactly the modules it needs (EchoAgents for agent orchestration, EchoAI for model governance, EchoCouncil for strategic deliberation, and so on) without paying for or standing up the ones it doesn't. Each module is billed, provisioned, and can be turned on or off independently. But every module you do subscribe to shares one identity graph, one permission model, and one audit trail. A user's access to EchoAgents and their access to EchoAI are both expressions of the same underlying capability grants, not two separate systems you have to reconcile.

Why this matters operationally

Two consequences follow directly from the model:

1. Onboarding and offboarding are single actions. Deprovision a user once at the core level, and their access to every module they touched disappears with it. There is no module-by-module offboarding checklist to forget an item on.
2. A permission change is legible everywhere. If you tighten a capability grant at the core level, every module that checks that capability enforces the tightened version immediately. You are not chasing down module-specific settings pages that drifted out of sync with each other.

Tenancy: shared vs. dedicated

Most organizations run on shared multi-tenant infrastructure with forced row-level isolation (Postgres RLS) between tenants: strong isolation, standard performance profile. Enterprise tenants can instead run a fully isolated private-VPC workload (dedicated Postgres, dedicated cache, dedicated object store) when compliance or scale requirements demand it. Either way, the module you're using behaves identically from the operator's seat; the tenancy model is a deployment decision, not a product-feature difference.

Where to look things up

When something behaves unexpectedly, first ask: is this a core-level behavior (identity, permissions, audit, billing) or a module-level behavior (a specific EchoAgents workflow, a specific EchoAI routing rule)? Core-level issues usually mean checking the identity/authorization admin views; module-level issues mean checking that module's own settings. This one triage question resolves most "why can't I do X" tickets before they need escalation.

Field exercise

List every EchoFoundry module your organization currently subscribes to. For each one, write down one setting or permission you believe lives at the core level and one you believe lives at the module level. Check both against the admin console and correct any you got wrong. This is the fastest way to build accurate intuition for the model.