Summary
Foundry is skillSYMS’ own operations surface for the platform’s modules: what exists, what each one depends on, whether it is healthy, who is entitled to it, and what it costs to run. It is platform staff only.
Who This Guide Is For
- skillSYMS platform operations, support and billing staff
Step 1: The Registry
Navigate to Foundry → Modules.
Every module on the platform with its code, its surfaces (the routes and APIs it owns) and its dependencies. When a provider asks “what does module X actually include”, this is the answer.
The module code here is what joins a module to its navigation entries. A module whose code does not match its nav registration is a module that is enabled and invisible — a failure that has shipped repeatedly and is worth checking first whenever a tenant reports a missing menu.
Step 2: Dependencies
Navigate to Foundry → Dependencies.
What a module needs in order to work. Read this before enabling something for a tenant: a module whose dependency is not provisioned will appear to work and then fail at the point of use, which is the worst place to discover it.
Step 3: Diagnostics and Findings
Navigate to Foundry → Findings.
The checks Foundry runs across the codebase and the deployed platform, and what they found.
Read findings sceptically. The first triage of this queue established that most findings were defects in the checker rather than in the platform — one check alone dropped from 1,381 to 390 findings once its own logic was corrected. Verify a finding against the real code or the real database before acting on it, and fix the check when the check is wrong.
Some checks query tables that do not exist in production. That is a finding about the checker.
Step 4: Entitlements and Plans
Navigate to Foundry → Entitlements.
Plans, packs and what each includes. Foundry → Tenants shows which provider is on which plan and what they can therefore reach.
Note that entitlement enforcement and entitlement record-keeping are not the same thing. Check what is actually enforced before telling a provider that something is restricted.
Step 5: Provisioning
Provisioning a module for a tenant is not the same as activating it. Provisioning makes it available; activation makes it appear. Both are needed and they are separate steps for a reason — a provider can be entitled to something ahead of being ready to use it.
Step 6: Metering and Margin
Navigate to Foundry → Meter for usage counters and rated lines, and Foundry → Margin for what modules cost against what they earn.
Metering is what makes AI, SMS and volume-based pricing possible. Check a tenant’s meter before a billing conversation, not during it.
Step 7: Deployment Facts
Navigate to Foundry → Deployment.
What is actually deployed where. This is the antidote to the platform’s most persistent failure mode: assuming a migration in the repository is a table in production. It is not, and this page is one of the places you can check rather than assume.
What Good Looks Like
- A finding is verified before it becomes work
- Dependencies are checked before provisioning
- Meters are read before billing conversations
- Nobody infers production state from the repository