SimpleTwo

One private network, and every rule is explicit. All the hosts share it: postgres and the s3 object store, the services that use them — messaging, calendar, identity, mail — and redis with the sfu nodes, and nothing between them but rules this control plane writes. The database accepts only the hosts that speak SQL — messaging, calendar, identity and mail — each as a /32 in pg_hba; the object store only messaging, the recorder and mail, each as a /32 on 9000; the bus only the services that dial it — the SFU nodes, the SIP bridge, the recorder — as a firewall rule on its own host. The plain-HTTP doors of identity, the calendar and mail answer on their host's private address only. Every list is recomputed on each state poll and applied within about a minute of a host appearing, so none of them is a rule somebody has to remember to keep true, and none needs a redeploy.

Host	Public	Private	Why
postgres	—	yes	only the hosts that speak SQL connect — messaging, calendar, identity and mail — each allowed as a /32; nothing else is admitted, and nothing needs to reach it from outside
messaging	yes	yes	clients talk to it, it talks to the database
s3	—	yes	object storage for attachments, avatars, recordings and mail (ADR-0043): only the messaging, recorder and mail hosts connect, each allowed as a /32 on 9000. Optional for chat — without it attachments live on the messaging host's own disk, which means one host, one backup and no second messaging replica — and required for mail, which does not start without one. Give the host a second, EMPTY disk and name it when you add the host: the platform makes it a ZFS pool for the objects, which is what makes a snapshot the backup. The alternative to the role is an endpoint the organisation already runs, in Settings → External stores
redis	—	yes	the coordination bus; no client ever touches it, and 6379 is open only to the services that dial it — the SFU nodes, the MCU, the PSTN gateway and the recorder. That rule is its whole boundary, so a host with no ufw and no firewalld is refused rather than left reachable from the network
sfu ×2	yes	yes	media and signalling are public; the bus is reached privately
turn	yes	—	a relay talks to clients and to nothing of ours
gateway	yes	DMZ only, into the corporate network	see ADR-0006; a geo gateway needs no private leg
support	—	DMZ, beside the coordinator	the support bot's daemon (ADR-0031/0034): inbound only from the messaging hosts (signed webhooks on :8087), outbound to messaging, to GitLab and to the model provider; no client and nothing public ever reaches it. It holds its own provider key — the bot's webhook points at it, and it calls the model itself — so there may be several such hosts, one per case: different jobs, different knowledge bases, different keys. Each is bound to its case when it is enrolled. It also keeps the bot's knowledge base: it reads the product's repository and issues from GitLab (one archive request on first sync, then only what changed) so the bot can answer instead of only filing bugs — so its GitLab token needs read_api on that project, not just issue creation
directory	with a name	yes	the directory and the calendar as one binary (ADR-0054 §5): people, groups, sign-in and the platform's tokens (ADR-0047) on its listen port and its public name — browsers and phones open that name for the sign-in, the portal and its console — and the calendars, their entries, the ICS feeds and CalDAV (ADR-0038) on 8085 and the calendar's own name, which subscription links point at. One database on the same postgres (the calendar's tables in their own schema), its own login, created for it automatically; it obtains its certificates for both names
mail	443	yes	the mailboxes (ADR-0042): rows in postgres, bytes in the object store; clients read and send over JMAP on its public name; the mx hosts deliver into it over LMTP, privately
mx ×2	yes	yes	the mail edge: MX for the internet on 25, submission on 587/465, delivery out on 25; no database and no mailbox, only its queue. Two, in different failure domains
monitoring	—	yes	metrics, logs and traces of every host (ADR-0048): the collectors send to it privately, people open it by name on 443
mcu	LAN or public	yes	the SIP bridge for meeting-room systems (ADR-0007): reachable from the rooms, the bus privately
pstn	public (carriers)	yes	the PSTN gateway (ADR-0053): the carriers' SIP trunks, audio only; the bus privately. Never on an MCU host — both want 5060 and the same media range
recorder	—	yes	records meetings: it dials out to the bus, the object store and the SFU, and nothing dials it

The one rule that silently breaks calls. A private address must never be advertised to clients. “Private address” goes in the host’s private address field; the address clients use goes in Advertise IP for an SFU. Put a private address in the second one and every call connects, carries no media and times out with nothing in any log.

Order. 1) postgres → 2) messaging → 3) calendar → 4) redis → 5) sfu node A → 6) sfu node B → 7) turn. Nothing needs redeploying afterwards: postgres re-reads its client list on every poll and admits each new host’s /32 within about a minute. Mail adds 8) s3 → 9) mail → 10) mx ×2: mail does not start without the object store, and identity goes before it when the people come from identity. Calendar is optional and can wait; until a calendar host exists the clients hide their calendar screens rather than offering buttons that fail, which is the honest answer for a deployment that has not stood one up. A second SFU node without redis is refused: two nodes without the bus each keep their own room table, so two people “in the same room” on different nodes cannot see each other and nothing reports a problem.

Sizing to start. postgres 2 vCPU / 4 GB / 40 GB SSD · messaging 2 vCPU / 4 GB (attachments live on its own disk unless an object store is configured) · s3 2 vCPU / 4 GB and a second, empty disk sized from the media rather than from the people — about 1 TB per 1000 people per year of chat files, doubling if meetings are recorded routinely, and about 1.9 TB more per 1000 people per year once mail is deployed; it is disk-bound, and neither CPU nor network is the limit at that size · redis 1 vCPU / 1 GB (it holds room routing, not data) · each sfu 4 vCPU / 8 GB and real bandwidth — an SFU forwards every stream to every participant, so the uplink is the limit long before CPU · turn 2 vCPU / 2 GB, bandwidth-bound for the same reason · recorder 4 vCPU / 4 GB per concurrent recording plus scratch disk — the one media role limited by CPU rather than bandwidth, since it records by driving a headless Chrome. It scales with recordings, not participants, and takes its jobs from the bus, so one worker serves the whole pool; it needs a machine of its own, since a host carries one role · calendar 2 vCPU / 4 GB — it holds no files, and its whole working set is rows in postgres; sized for the polling rather than for the people, since a subscribed Outlook and a CalDAV client come back on their own schedule whether anybody is looking or not · support 1 vCPU / 2 GB / 10 GB — two small Go daemons plus the knowledge base, which is held in memory (a repository the size of this one is ~6k chunks ≈ 100 MB with embeddings, and its file on disk is the same order); searches are index-backed and answer in under a millisecond, so the single core is the model provider's problem, not ours. The thinking happens provider-side, so nothing here grows with chat load the way media hosts do. Deploy it last: it needs messaging live and the support case’s provisioning (AI & automation → Support case) run, in either order.

Ports the deploy opens for you (host firewall, when ufw or firewalld is present): sfu 7881/tcp and 50000-60000/udp, plus 443/tcp once its certificate exists — 7880/tcp only on a node with no public name, because a named node keeps signalling on loopback behind its TLS front · turn 3478/udp+tcp and 49152-65535/udp, plus 443/tcp once its certificate exists · mcu 5060/udp+tcp and 10000-20000/udp+tcp · pstn 5060/udp+tcp and its RTP range/udp (10000-20000 unless set), plus 5061/tcp once its certificate exists · recorder nothing at all · messaging its listen port, plus 443 when it terminates its own TLS · calendar 443 once it has a public name, and its listen port (:8085 by default), answering on the private address only · identity its listen port (:8086 by default, on the private address only), 443 with a public name, and 636/389 when its LDAP server is on · mail its listen port (:8087 by default, on the private address only), 24/tcp to the mx hosts only, and 443 once it has a public name · mx 25/tcp, 587 and 465/tcp once it has a public name, and 2525/tcp to the mail nodes only · postgres 5432/tcp to each SQL client’s /32 — messaging, calendar, identity, mail · monitoring 443/tcp, and 4319/tcp to the hosts whose collectors send to it. And 80/tcp on every host whose certificate this coordinator orders (sfu, turn, mx, monitoring), from its first order on: it stays open for renewals, and nothing listens on it between orders. Three ports are never opened to the world, and on a host with no firewall tooling the deploy fails rather than leave them reachable: redis 6379, only to the addresses that dial the bus — the SFU nodes, the MCU, the PSTN gateway, the recorder; s3 9000, only to messaging, the recorder and mail; monitoring 4319, only to the hosts whose collectors send to it. With one private network that rule is the only boundary each of them has, so it fails whatever address the service listens on. postgres, mail’s 24 and the edge’s 2525 are narrowed the same way but do not fail without a firewall: pg_hba, and the mail roles’ own check of who is calling, are then their only boundary.

Certificates. messaging obtains its own (autocert) for its public name — the one given at enrolment or in its Settings. Calendar, identity and mail do the same, and for the same reason they are allowed to: they are our own Go services, so they run ACME themselves (TLS-ALPN on 443). An SFU cannot — that is the whole reason edge exists — and the difference is worth knowing when a role seems to be missing a certificate button. Subscription links are built from the calendar's name, so it must already resolve to the host before the certificate can be issued. An SFU needs TLS in front of 7880 for iOS to connect at all, and an enrolled host no longer needs you to arrange that: the coordinator runs the ACME order and the host serves the one challenge file on port 80, because the name points at the host while the account key stays here. So 80/tcp must reach the host from the internet — the agent opens it in the host's own firewall and leaves it open for renewals; a firewall or NAT in front of the host has to pass it too. From the moment an SFU has a name its signalling is on loopback, so it takes no calls until that certificate is on disk. The edge front then terminates 443 and proxies every path to 7880 — every path, since moderation arrives on the same host and port as the client’s WebSocket, and a front that forwards only the socket breaks mute and remove while calls still look fine. The relay and the mail edge get theirs the same way — coturn reads the files on 443, mx presents its certificate for STARTTLS on 25 and on 587/465 — and a name ACME cannot validate takes an imported certificate (import on the row).

The host joins by running one command on itself (ADR-0025) — no SSH key here, no inbound reachability needed, so a machine in a private network works the same as a public one. The invitation is single-use and expires in an hour; the host exchanges it for its own credential and then pulls what its role needs. Guide: deployment

Loading… Guide: single sign-on

Who this installation is on the wire, and which organizations it exchanges messages with. Federation is a contract between two administrators: each side lists the other, and a one-sided setup is refused by the other side — which is correct behaviour, not a misconfiguration. There are no shared secrets to exchange: each installation signs with its own key and publishes the public half, so parting company is a line removed from a list. Guide: federation

How the door is held. Today it is held by this list and nothing else — a message is accepted when the sending domain is on it, its signature verifies, and we have not seen that message before.

ADR-0020. How much history a client puts on the device at its FIRST sync, so it opens without a connection. The people list, the conversation list and the calendar list are synced whole and need no number — their size is bounded by the organization. Message history is not, so it is fetched by a stated depth: the newest N conversations, M messages each. Bigger means more works offline and a longer first sign-in; the clients cap it at 200 × 500 whatever is set here. Leave both blank and every client uses its own documented default (20 × 50) — which is a different thing from setting 0, and the storage screen on the device says which of the two it is. Applies at the next sign-in or fresh install; devices already warmed keep what they hold.

Server-side rules (ADR-0014): a trigger (bot mention / keyword / schedule / webhook) runs linear steps; a step with an approve gate pauses until an allowed human reacts ✅ in the chat. Every rule speaks as a bot (as) and posts only into rooms that bot is a MEMBER of — so the member list answers "who can write here", and removing the bot from a room revokes it.

Everything non-humans did — bot mutations, automation runs, approvals — merged from the coordinator and messaging audit trails.

ADR-0021 §2. An assistant is a virtual session of one person — it reads everything they can read and posts in their name. This switch decides whether this organization may have them at all. The messaging service checks it on every request, not only when an assistant is created, so turning it off stops the ones already running rather than waiting for their tokens to expire. Worker bots — which act under their own names and see only the conversations they were added to — are not governed by it.

The tenant's model-provider key behind the /ai/v1/* proxy (ADR-0030 §2). Bots never see it — each holds its own ai_… token, issued per bot in the Bots table with a model allowlist and a daily budget. Same rule as push keys: saving is enough, the messaging host's agent applies it within a minute. Check ai in the messaging /healthz. Guide: the AI lane

Personal quotas (token API). An assistant spends its owner's own quota at the gateway and never this tenant key — with no quota it is created without a brain, deliberately. Give the installation address and an Admin-role token, and each person's key is issued when they create their assistant and revoked with their account. The management routes live outside /v1.

One button stands the whole thing up, idempotently (ADR-0023 Part 3): the Welcome Bot with a system badge, the welcome channel, the bot's membership in it, and the rule that greets whoever appears. Everything it creates stays an ordinary object afterwards — the bot on the Bots page, the room in the client, the rules in Automations — so an administrator edits the greeting there and re-running converges the rest around it.

The trigger is user_created, which the coordinator reports for an admin-created account and for a first SSO login. It greets people only — meeting rooms and bots are accounts too, and they used to be welcomed to the company alongside them. Membership is by invitation — the bot adds people as they appear — so anyone who joined the company before this was switched on is missing until you fill the room below.

The greeting is your text, not a product string: it lives in the rule and is never translated for you. Placeholders: {{display_name}}, {{user}}, {{company}}, {{department}}, {{title}}.

One button stands the whole ADR-0031 case up, idempotently: the bot (system badge, @librarian), its AI token, the «SimpleTwo Support» channel and «SimpleTwo Dev» room, the gated automation and the webhook secrets. Re-running converges rooms/automation and rotates both bot tokens — the support node picks them up on its next convergence. Then: enroll a support role host (Servers), add people to «SimpleTwo Dev», grant them the dev role. Requires the AI lane above.

There may be several such servers — different jobs, different knowledge bases, each with its own bot and its own provider key (ADR-0031 §5). Each is a case: pick one to edit it, or name a new one to stand another up. A support host is bound to its case when it is enrolled.

Names are per-install; blank keeps the current ones (defaults on first run). Rooms are tracked by id once created — room titles here only matter at first creation, and renaming a room later in the client is free.

This server's OWN provider credential (ADR-0031): the intermediary the bot's webhook points at calls the model itself, with a key limited upstream. Several such servers — different jobs, different knowledge bases — never share one. Leave the key blank to keep the stored one, or leave it unset to fall back to the platform lane.

Knowledge base (ADR-0034): the bot learns the product from GitLab — code, docs and issue history — so it can answer instead of only filing bugs. Blank fields keep the current settings; the embedding model must also be in the bot's AI allowlist, and needs an OpenAI-compatible provider (without one the base still searches lexically).

The records each mail domain must publish for the edge (mx) to receive and send its mail: MX, SPF, DMARC, the DKIM keys this coordinator generated for the edge, and the submission and JMAP discovery records. Each is looked up; a record marked missing is one the world cannot see yet. Click a value to copy it.

The addresses every mail domain must answer at: postmaster@ (required by RFC 5321), abuse@ (complaints about mail from here), and dmarc@ and tls-reports@, where the domain's DNS records ask others to send their reports. Missing ones are made as identity groups that cannot be deleted by accident and that anyone may write to, with you as the first member; add the people who answer them in Users → Groups.

Machines on the internal network that cannot sign in with a password — scanners, an ERP, monitoring. They connect to the mail edge (mx) on port 25 from the networks listed here and may write only as the senders listed, in this installation's mail domains. Everything else stays with app passwords. The internal network must be able to reach the edge's port 25.

Networks and senders: several, separated by commas. A sender is an address or a whole domain as @corp.example. The narrowest network decides which connector a machine belongs to.

What the mail edge (mx) checks on mail from the internet, and where it hands mail out. The content filters are the organisation's own services — rspamd or clamav-milter over milter, an anti-virus over ICAP — asked in this order; the edge runs none itself. Every mx node takes these settings on its next poll and restarts with them. An empty field keeps the edge's default.

Address: inet:10.0.0.5:11332 or unix:/run/rspamd/milter.sock for a milter, icap://av.corp.example:1344/respmod for ICAP. A filter that does not answer lets mail through unchecked (open) or keeps it waiting at the senders (closed). Virus headers: the headers your anti-virus answers with when it finds something; empty is the common products' own.

587 and 465: empty or 0 is no bound, the default. A bound per address counts everyone behind one NAT as one client (an IPv6 network by its /64).

Block and allow lists: zones separated by commas, zone=127.0.0.2|127.0.0.4 to count only those answers, off for none; empty is zen.spamhaus.org and no allow list. Connections: 0 is no bound. The relay: empty delivers to each recipient's MX directly — set it when the provider blocks outbound port 25; several, separated by commas, are tried in turn. A trusted ARC sealer — a domain, with its subdomains — lets a message whose DMARC failed through when its chain passes and that sealer found DMARC passing; with none, chains are recorded and decide nothing.

Mail the anti-virus or a content filter held on the way in. The sender was told it was delivered; each recipient got a notice from the postmaster instead of the message. Only here can it be released to its recipients or deleted; what nobody decides on is deleted after 30 days (MAIL_QUARANTINE_DAYS).

Partners and other outside addresses in groups whose mail comes back. After five bounces in a row, each within a week of the last, a member is disabled: its copies stop until you enable it again here — do that once the address works again.

What comes back from a group's members outside is kept in the mailbox named here for the group, and that mailbox gets a letter when a member is disabled. With none named, or while that mailbox is archived or belongs to a person who has left, the postmaster of the group's domain gets them.

Every mailbox the mail role holds: people's, made from the directory; shared ones, made here; rooms and resources. A shared mailbox has a responsible person and the people or groups who may open it, each with what they may do and whether they may send as it. A legal hold stops retention and any cleanup from destroying the mailbox's mail, whoever it belongs to.

Who may write to a group is identity's rule (the group's writers). Here is who may send AS the group, from the group's own address: as — the message is the group's alone; on behalf — it names the person in Sender. Every message sent as a group is written to the access audit.

The path of a message, from the edge that took it to a mailbox or a remote server: search by an address, or by the queue id either side gave (a bounce and the sender's server name it). Who wrote to whom is personal data, so this card needs the audit:read permission.

What the submission doors (587 and 465) refused is listed under the path — a device or a program that cannot send: search by its login or sender address, or by its IP address or network. Repeated refusals are counted, not listed one by one. A wrong app password or a locked account is also in identity's sign-in records, with the client's address.

Who opened which mailbox and did what: access to shared mailboxes and through delegation, and always what changes who can reach a mailbox or where its mail goes — a recall, an import or export, sending as somebody, an app password, a release from quarantine. It holds no subject and no body. Needs the audit:read permission; the export is JSON lines for a SIEM.

A text added to every message a person sends from the domain, to every recipient, before the edge signs it. The marker is how a reply that already carries it is recognised, so it is not added twice.

A person's mailbox outlives their account: kept indefinitely unless a policy is set. With one, it is archived — accepts no mail and stays readable — or purged after the days below, and the responsible person is told before. A mailbox under legal hold is never purged; one made shared is the organisation's and is left alone. To find them, filter Mailboxes by "left by a person who has gone".

How long deleted mail lives. Trash and Junk are emptied after their days. What is deleted — from there, by a person, by a recall or by the leavers' purge — leaves every device and waits out the recovery window whole, so that you can bring it back; then it is erased for good, and its bytes a day later. A mailbox under legal hold erases nothing, and its people can still delete. Guide: mail

0 for Trash or Junk: never emptied. 0 for the window: deleted mail is erased within the hour.

Whether a person's rule may forward a copy of their mail to an address outside the organisation. Off, such a rule forwards nothing outside — the way most organisations keep it, because a forwarding rule is how mail leaks. On, the copy leaves with its envelope rewritten (SRS), so that a bounce finds its way back to the sender, and sealed with ARC; mail the filters judged junk is never forwarded. The list shows every mailbox whose rules forward outside, whether or not it is on. Guide: mail

The aggregate reports sent to the domains that ask for them, one a day per domain, for the last thirty days — or why one went to nobody.

The TLS reports (RFC 8460) sent to the domains that ask for them, one a day per domain, for the last thirty days: how many sessions to their mail servers negotiated TLS and how many failed — or why a report went to nobody. A domain asks with its _smtp._tls record; reports go to mailto: addresses only.

Charged against stored is the number worth watching: the drive stores the same file once however many people keep it, and the gap between the two is what that is saving you. A space whose quota is spent stops accepting new files and goes on serving the ones it has.

The files people see, the bin and the earlier versions are three different costs, and only the first shows in anybody's file list. The largest files are the quickest to free: a file in the bin goes by itself when its days are up.

A person's own space is made for them when they are given the drive; a shared space is made on purpose — here, or in the app by somebody with the right to — and is opened to groups and people at a level. A quota of 0 means the installation's default applies; setting one below what is already stored refuses new files and takes nothing away.

A person who leaves keeps their files here, read-only for everybody, under the same rules as their mailbox: the retention policy, the responsible person and the legal hold are set on the mailbox (Mail, Mailboxes), and the files follow it. Making the mailbox a shared one keeps the files too, managed by its responsible person.

What the Dashboard and the sign-in screen offer people as a way to install SimpleTwo. Store links go to TestFlight / Google Play; the rest are builds hosted here, in the coordinator's data volume. Both the list and the downloads are public — the person who needs a client cannot sign in from one yet. Guide: client apps

ADR-0039. One master key, kept in a file on this server outside the database's volume, and printed on a recovery sheet with a QR code. The working keys — message bodies, the blind search index, meeting transcripts — are derived from it, so the safe holds one sheet rather than one per purpose. Generating, rotating and re-printing need the encryption:keys permission and leave a line in the audit log; reading a body in the clear needs messages:export. Neither is in any built-in role.

New generation re-derives the working keys from the same master: new writes use them, old rows keep opening, and the printed sheet stays valid — this is the answer to a key that may have leaked from a messaging host. New master key prints a new sheet, and rows already sealed keep needing the old one.

The core — the coordinator, Chats and the directory with the calendar — is always on; everything else is an option: switch it per tenant and, where it applies, choose HOW it is reached — directly over TLS (works without the VPN) or through the tunnel only. Clients hide disabled modules. Secure Access is the VPN itself — the gateways and the tunnel; off, no gateway is enrolled and every mode here reads direct. Audio/Video has a tier: Basic is calls, conferences and recording; Plus adds rooms (the MCU), telephony with PSTN, call recording, federation, transcripts and the AI support. Skills (peer-confirmed skills, endorsements, kudos) is served by messaging and follows its access mode; it ships OFF, because collecting this about people is a decision an organization makes rather than one it discovers. Federation lets people here write to name@another-domain and is the one switch that lets messages leave this organization — it ships OFF, needs the policy below and Audio/Video Plus. ID is identity as the provider; off, identity is the directory alone. Greyed rows are designed and not built.

Camouflage each gateway under a country-plausible host (RU→yandex.ru, NL→a .nl site). Verify on the gateway with xray tls ping <host> — pick one showing Post-Quantum: false (X25519). Per-gateway blank = inherit global. Applies after the gateway's next Update.

XTLS-Vision. Splices the inner TLS so a DPI cannot see TLS-inside-TLS — the fingerprint plain VLESS+Reality carries, and the one a path that kills established flows keys on. It is the designed answer to "the tunnel connects and passes nothing". The risk is the mirror image: the mobile (libXray) build has been measured negotiating Vision and never relaying the RESPONSE — gateway acknowledges, fetches, and sends a FIN with zero data. One switch for the whole install, because both ends must agree: gateways re-render within a heartbeat, clients pick it up on their next session. Turn it off here the moment mobile goes quiet.

Use stores the organisation already runs instead of the ones the postgres, redis and s3 roles install. Leave a field empty and that store keeps coming from its role — this is a switch, not a migration: nothing is copied, so point a service at a new database only when it is empty or already holds its data. Guide: storage

Give each service a connection string its own login can use. We do not create databases or roles here: a cluster you do not own will not grant that, and half-creating something on it is worse than asking.

Checks dial from the coordinator. The host running the role still needs its own route to the database — that is the one thing this button cannot see. Saved values reach a role on its next poll, and the service restarts with them.

One key, both kinds of push. This is not calls-only: the same APNs key rings incoming calls and delivers every message notification. Leave it blank and users get no message banners at all — the messaging service builds no APNs client and every notification silently becomes a no-op. Saving is enough: the key is part of the messaging host’s desired state, so its agent picks the change up on its next poll (about a minute) and restarts the service. Nothing to redeploy — a host that pulls has no redeploy.

Leave OFF for TestFlight and App Store builds — they are signed aps-environment: production, and the sandbox host rejects their tokens as BadDeviceToken. Only a Xcode-built debug install needs this.

The Android half of the same story: without it Android devices get notifications only while the app is open. Same rule as APNs — saving is enough, the messaging host’s agent applies it within a minute and restarts the service. Check push_android in the messaging /healthz to see it land.

Firebase console → Project settings → Service accounts → Generate new private key. This is not google-services.json: that one is the client config, it belongs in the Android build (CI variable ANDROID_GOOGLE_SERVICES_JSON), and it is rejected here.

The organisation's directory and the platform's sign-in (ADR-0047 §8a): people, groups and their membership, the attribute schema, address books, applications, company providers, SCIM, the LDAP server and the sign-in policy are identity's, and are managed in its own console (the link above). This card is the role's status, like every other role's. Guide: groups and the schema

One local account on the coordinator for the day identity is down and the fleet — identity included — has to be repaired (ADR-0047 §8a). A password and a mandatory authenticator code, held here and never on identity. It signs in only at its own address, every use is audited and every administrator is messaged, and its session opens this console for an hour. Keep the password and the authenticator somewhere the on-call administrator can reach without the platform.

Four switches. Platform token: who signs people in — this coordinator (hmac, today) or identity, whose token every service then accepts alone. Service token: what the services sign their calls to each other with — the shared secret (hmac) or each host's own key. CalDAV and CardDAV: what a calendar or contacts program signs in with — the calendar's device passwords (calendar, today) or identity's app passwords alone. Messaging directory: where chat takes people and groups from — this coordinator's directory events (coordinator, today) or identity's directory feed, which shows chat only the people provisioned for it. Each switch refuses to move forward while anything below stands in its way; switching back is always allowed. Runbook: switching to identity

The migration tool moves data with a wave's credential, which identity issues and which reaches only the wave's people. The stopgap is the old way in: a plain svc:move service token signed with the shared secret, which names no wave and so reaches every person's books on identity and the calendar. It is shut. An owner may open it for at most 72 hours, with a reason; identity and the calendar close it by their own clocks at that instant. Every use is audited on the role and counted in its /healthz, and every administrator is told when it opens or closes.

Warning: while it is open, anyone holding the shared secret can read and write every person's address books. Open it only for a migration run that cannot use a wave's credential, for as short a time as the run needs, and close it as soon as the run ends.

This card feeds identity's directory (ADR-0047 §8a). Its passes run on the coordinator only until identity takes them: as soon as an identity host is deployed, the coordinator hands it the connection, the bind password, the watermarks and the last results once, and deletes its own copies. Without identity they stay here. The photo policy below stays here either way.

Employee avatars are pulled from AD (thumbnailPhoto) after each SSO login and pushed to messaging. Guests/external accounts upload their own photo in the app.

This card feeds identity's directory (ADR-0047 §8a). The HRMS module runs on the coordinator only until identity takes it: as soon as an identity host is deployed, the coordinator hands it the connection, its secret, the settings and the last run once, and deletes its own copies. Without identity it stays here.

One connection to a SimpleOne instance, shared by every module integration; HRMS is the first. It enriches employee cards with the two managers an organization actually has — functional and organizational — which AD cannot express, since it carries a single manager. Plain directory data: nothing here is behind the Skills switch. We always call them, never the reverse (their Scripted REST executes as Guest User on a bad token).