| Agent | A z4j process running inside your app, connected to the brain via WebSocket. One per app process. |
| Brain | The central z4j server - FastAPI + React dashboard + Postgres. One per organization. |
| Broker | The message transport underneath your queue engine (Redis, RabbitMQ, SQS). z4j observes queues but does not act as a broker. |
| Capability map | JSON object each agent sends in hello, advertising which actions it supports natively vs. which need polyfill. |
| Control plane | The management layer that observes and acts on task infrastructure without participating in the task runtime. |
| Engine | A Python task-queue library (Celery, RQ, Dramatiq, Huey, arq, taskiq). z4j adapts to each. |
| Engine adapter | A z4j pip package (z4j-celery, etc.) that bridges engine-specific APIs to the z4j wire protocol. |
| Event | A timestamped record of a task lifecycle transition (task_sent, task_started, task_succeeded, …). |
| Framework adapter | A z4j pip package (z4j-django, etc.) that hooks into the framework’s boot and settings. |
| HMAC chain | The audit log’s tamper-evidence mechanism - each row’s HMAC depends on the previous row’s. |
| Polyfill | When the brain implements an action that the engine doesn’t expose natively (e.g., bulk retry for arq). |
| Project | The tenancy boundary in z4j. Agents, tasks, users - all scoped to a project. |
| Reconciliation | The background process that finds “started-forever” tasks and queries the agent about their real state. |
| Redaction | Stripping secrets from event payloads before they leave the agent. |
| Scheduler | A periodic-task system paired with an engine (celery-beat, rq-scheduler, APScheduler, etc.). |
| Scheduler adapter | A z4j pip package (z4j-celerybeat, etc.) that bridges schedule discovery and CRUD. |
| Setup URL | The first-boot one-shot URL the brain prints so the operator can create the initial admin. |
| Wire protocol | The JSON-over-WebSocket framing that agents and the brain speak. Versioned; currently v1. |
