Security foundation
The isolation proof
Before anything else is built, Elites Only Club must demonstrate that one organisation can never reach another organisation's records. Authorisation is decided by the database on every single request. Hiding something in the interface is not security, and no part of this build relies on it.
01
Use the three fictional verification identities
Use the established Member A, Member B and Specialist identities. Temporary seeded signup assignment is disabled. New accounts require confirmed email and receive no organisation access; a separate privileged invitation-acceptance workflow is required before participation.
02
Member A
Signed in as Member A, the dashboard shows Organisation A and Demand A. Organisation B and Asset B are absent — not hidden, absent: the database returns no rows for them.
03
Member B
Signed in as Member B, the dashboard shows Organisation B and Asset B only. Organisation A and Demand A are not returned.
04
Identifier manipulation
While signed in as Member A, request Asset B by its exact identifier through the data API. The response is empty, and an attempt to update or insert a record against Organisation B is rejected. The same holds in reverse for Member B.
05
Specialist
Signed in as the specialist, both organisations and both records are visible — solely because the Elites Only Club Specialist role is explicitly granted. Remove that role and the same account sees nothing, despite being fully authenticated.
06
Deletion
No account of any kind can delete a demand, an asset, an organisation or a membership. Records are archived with a timestamp so history remains available for later audit work.
Fictional test records
- Organisation A — Test Organisation A (Fictional Family Office)
- Demand A — Fictional co-investment mandate
- Organisation B — Test Organisation B (Fictional Asset Owner)
- Asset B — Fictional infrastructure holding
No real Elites Only Club information is present anywhere in this build.