These follow you into every workspace.
| Workspace | Your role | Can sign? |
|---|
Click a workspace to switch to it. Your role is set per workspace by an
administrator — you can be admin in one and viewer in another.
Name, portrait, password and two-factor are handled by your sign-in provider. Open account settings ▸
Welcome. Sign in to continue.
| Raw material | g / serving | g / unit | Excel | Total kg | Excel | % of blend |
|---|
This is TRG's real formula, scaled by the engine. The “Excel” columns are what the spreadsheet says. Change the unit count and watch the batch scale — fill weight and capsule count don't move, because they're properties of the recipe, not the batch.
Look at the % sum. Ours is exactly 1; the spreadsheet's is 0.999999999958937 — Excel just displays “1”. That's why we store grams and derive the percentage, never the reverse.
Capsules per serving = fill weight ÷ capsule capacity, rounded up. 40.0001022 ÷ 0.74 = 54.05 → 55. Rounding down would ship a serving under its label claim.
| Tenant | Name | Kind | Timezone | Members | Audit entries |
|---|
| Subject | Tenant | Role | Can sign? | Granted by |
|---|
| Subject | Granted by | Reason |
|---|
Revoking platform admin demotes rather than deletes — it removes their
view of every tenant and leaves their own tenant memberships exactly as they were.
Someone who was admin on TRG goes back to being admin on TRG,
and nothing more. If they hold no memberships at all, they keep a working sign-in that
sees nothing, and can be invited to a tenant like anyone else.
| Tenant | Role | Invited by | Reason | Status |
|---|
This is the only screen that crosses tenant boundaries — which makes it the one place a bug could show one manufacturer another's formulations. So it's read-mostly, it shows counts rather than contents, and every grant is written into that tenant's own audit chain.
That last part is the point. When a customer asks “can you see our formulations?”, “we wouldn't do that” is worthless. “Yes — and it's in your audit trail, which you can read, and which we cannot alter” is a real answer, and it's only true because of this.
A platform admin is not a tenant admin. Todd is admin on TRG — he runs it, and he must never see Acme. This screen is a separate identity check, not a role flag, so the two can't drift into each other.
A grant requires a reason. An admin write is audited harder than a user's — who, what, and why.
Roles are per tenant. The same person can be admin on TRG and viewer on Acme, or absent from Acme entirely — access is a row per tenant, not a rank that follows someone around. Inviting them twice, to two tenants, with two roles, is the normal case rather than a special one.
Root cannot be removed. Not by another admin, not by the app, not by root. A Postgres trigger refuses the delete, so it holds even against the database owner — because the only account that can repair a broken admin screen must not be deletable by a broken admin screen. Only root can add or remove other platform admins: an admin who could mint admins can make more of themselves.
| Seq | Action | Entity | Actor | Reason | Ver | Prev hash | Hash |
|---|
Try the red button. It runs UPDATE audit_entries… as the database owner — the most privileged role there is. Postgres refuses: a trigger binds every role, so history cannot be rewritten even with full database access. The hash chain proves a tamper; this prevents one.
“UPDATE with no reason” is refused — §11.10(e) says a changed record must say why, enforced in code and as a database constraint.
Switch tenants (top right): same page, same code, different data. Postgres row-level security enforces it — a query that forgot its WHERE clause still cannot leak.