Appearance
IIP Documentation Index
Technical documentation for the Intern Integration Platform (IIP) — a service-oriented, event-driven integration middleware built around Kafka, a canonical schema-enforced data contract, and pluggable idempotent adapters.
These docs describe the full platform, not just an MVP slice. This is a solo project — one developer building everything the original design brief described, including what it labeled "Phase 2" — that work is simply sequenced into later releases (see the implementation plan), not cut from scope. Development follows Extreme Programming (XP), adapted to a single-developer context (see Implementation Plan §1): small continuously-integrated releases ordered by value and dependency, not by fixed dates or hour estimates — so none of these documents contain a schedule.
Documents
| Doc | Contents |
|---|---|
| 00 — Original Specification | The source design brief, preserved as authored, for historical context. |
| 01 — Architecture | System context (C4-L1), containers (C4-L2), key components (C4-L3), data-flow sequence diagrams, topic/partitioning design, deployment view, tech stack, and the key architectural decisions with rationale. |
| 02 — Use Cases | Actors, use case diagram, and 12 detailed use cases (UC-1 … UC-12) covering intake, fan-out, failure recovery, DLQ handling, extensibility, monitoring, and DLQ replay — each tagged with the release it belongs to. |
| 03 — Data Model | The canonical event schema and its lifecycle variants, the DLQ envelope, target storage models (PostgreSQL ERD, CSV format), and schema evolution/compatibility rules. |
| 04 — Implementation Plan | XP-based release roadmap (Releases 1–7) covering the entire system, backlog with acceptance criteria per story, cross-release engineering practices, Definition of Done, and a risk register. |
| 05 — Phased Rollout | Each release broken into small, sequential, checkbox-tracked implementation phases — the working execution checklist for actually building the system, one commit-sized step at a time. |
Reading order
- New to the project? Read them in numeric order: 00 → 01 → 02 → 03 → 04.
- Reviewing the architecture specifically? 01, then 03 for the contract details.
- Actually building something right now? Go straight to 05 and pick up the next unchecked phase.
How these docs stay accurate
Every capability described in 01–03 is tagged with the release (from 04) that introduces it, so as the platform grows past the MVP these documents don't need a rewrite — only incremental updates as each release lands. Per the Definition of Done, every story checks whether it changes architecture, a use case, or the data model enough to require a docs diff. Doc 05 is the exception — it's a living checklist, expected to change every time a phase lands.