---
name: iios-relationship
description: How this demo relates to the IIOS service/SDKs at D:\iios (reference only)
metadata:
  type: reference
---

The **IIOS** monorepo lives at `D:\iios` — a NestJS service (`packages/iios-service`, port
3200) plus React SDKs (`iios-message-web`, `iios-inbox-web`, `iios-support-web`,
`iios-community-web`, `iios-ai-web`, `iios-meeting-web`) over a low-level `iios-kernel-client`.
It treats every interaction (message, ticket, route decision, AI proposal, meeting) as one
governed `Interaction` behind fail-closed policy/consent gates.

**This repo is standalone and does NOT import or call IIOS.** IIOS was used only to model the
domain vocabulary and the surfaces to build. Deliberate parallels so a later swap is easy:

| This repo | IIOS analogue |
|---|---|
| `Message` / `Channel` / thread | `Message` / `Conversation`(`IiosThread`) / parent-child interactions |
| `InboxItem` (NEEDS_REPLY, MENTION…) | inbox projector items (`iios-inbox-web`) |
| `Ticket` (state/priority, escalate, callback) | `iios-support-web` tickets/escalate/callbacks |
| `BffClient` → `/api/bff/**` | `RestClient` → `iios-service` `/v1/**` |
| feature flags / theming | app-level concerns (IIOS is backend-governed) |

**Live wiring is built AND proven.** The BFF uses a `Backend` interface (`apps/web/lib/backend/`);
`BFF_BACKEND=iios` swaps in `iios.ts` → real `iios-service` via `lib/iios/client.ts` (dev-token
auth) + `map.ts` (shape mappers). This was run end-to-end: IIOS service on :3200 against a native
Postgres (role `iios`/`iios`, db `iios` on **:5432** — no Docker needed; a separate :5434 cluster
crashed under the sandbox's process/shared-memory limits, so the existing service on 5432 was used),
9 migrations applied, an ingested message read back through this app's BFF. Default stays mock
(rich demo data; fresh IIOS DB is empty and has no channel-directory endpoint). Exact steps:
`docs/IIOS_INTEGRATION.md`. Related: [[architecture-decisions]], [[qa-and-fixes]].