01
Scope
Who needs the workflow, what is visible, and what stays out.
Loading this page.
Trust boundary · Identity
Six-digit email codes verify mailbox reachability only. They do not reset provider passwords inside Quoalis, replace MFA/passkey step-up, approve spending, grant property scope, or authorize account changes.
Module proof path
See the workflow, proof, and operating limits in one scan before reviewing the detailed path.
Inspect proof Open demoWho needs the workflow, what is visible, and what stays out.
Screenshot, proof card, or demo path that makes the claim inspectable.
What requires human review or source evidence.
Why this page is short
Some areas are intentionally represented by a narrow public boundary instead of a full feature page. That keeps sensitive operations, access rules, and unfinished marketing claims out of the buyer-facing experience.
How we evidence thisEnforced boundary
Six-digit email codes verify mailbox reachability only. They do not reset provider passwords inside Quoalis, replace MFA/passkey step-up, approve spending, grant property scope, or authorize account changes.
EMAIL_CHALLENGE_BOUNDARY · apps/api/src/ironbound_api/modules/identity/accounts_router.py:143
4 further boundary constants in this module
This lists which properties one account stands in a relationship to, and on what terms. It is not a directory of people: it carries no name, email address, phone number, subject id or membership id, and it answers only for an account the caller may already read. There is no workspace-wide listing of who is connected to what.
PROPERTY_RELATIONSHIP_BOUNDARY · apps/api/src/ironbound_api/modules/identity/accounts_router.py:3401The workspace roster lists active members who may hold assigned work, so a person can be chosen instead of typed. It is not a directory, an org chart, or a contact list: it carries no email address, phone number, account identifier, or employment detail, and it excludes owner and vendor personas entirely.
WORKSPACE_ROSTER_BOUNDARY · apps/api/src/ironbound_api/modules/identity/accounts_router.py:3497A succession ends one role grant and begins another at a single instant, in one transaction. The window is half-open, so at that instant exactly one membership holds the role: there is no moment when both hold it and none when neither does. The outgoing grant is given no grace period, because a handover is not a lapse and a grace period would create the overlap this endpoint exists to prevent.
ROLE_SUCCESSION_BOUNDARY · apps/api/src/ironbound_api/modules/identity/accounts_router.py:3547Effective access reports only the enforced model: role capabilities from ROLE_CAPABILITIES narrowed by the access row's allowlist, the properties actually in scope, and -- for owner personas -- the owner authority policy that gates approvals. It is not a directory: it carries no name, email address, phone number, or employment detail. It excludes the assignment-role and proposed-permission vocabularies, which are display models that enforce nothing.
EFFECTIVE_ACCESS_BOUNDARY · apps/api/src/ironbound_api/modules/identity/effective_access.py:71Copied verbatim from apps/api/src/ironbound_api/modules/identity/router.py and regenerated from apps/api/src/ironbound_api/modules. The API returns these same strings in its boundary fields, and a drift check fails the build if this page and the source stop agreeing.
Pilot access
The best demo is not a feature checklist. It follows a request from owner intake to manager triage, vendor packet, field evidence, reviewed closeout, and owner-safe reporting.
We respond with the recommended demo route, who should attend, and what production access would require.