Continuous Coordination Server

Runnable reference server for the Continuous Coordination schema.

What it is

Continuous Coordination is a set of practices for keeping teams, people, and AI agents in sync through two structured loops -- daily team check-ins and recurring goal story updates. The schema repo defines the shape of the data that flows through those loops.

This is the open-source reference implementation: a small REST service intended for tool authors testing against the spec and teams running their own coordination data store. It ships the six schema entities (actors, teams, team check-ins, goal stories, goal story updates, coordination events) over REST, built on PostgREST over PostgreSQL. The API is auto-generated from the SQL schema -- there is no hand-written application layer. Single-tenant, no auth. Drop it behind your own gateway if you need either.

Quickstart

Run the server

docker compose up -d

Four containers come up:

• PostgreSQL 18 -- data store, initialized from db/init/01_schema.sql on first boot.
• PostgREST on http://localhost:2626 -- the REST API.
• Swagger UI on http://localhost:2627 -- interactive API docs reading PostgREST's auto-generated OpenAPI spec.
• Viewer on http://localhost:2628 -- a tiny static HTML page that lists all six entities in tables. Read-only, no setup, mobile-responsive. Open it in a browser to browse the data.

The first start pulls images and runs the schema migration; subsequent starts are fast. Set POSTGRES_PASSWORD in your environment for anything beyond local play.

Optional: load example data

bin/seed

Populates the database with three teams (Backend, Frontend, Marketing), 11 people and 3 agents, a "Launch PSC 2.0" goal story with three sub-goals, a week of team check-ins (~75% coverage), and goal updates from each goal owner. Re-running replaces the demo data; reset to a clean DB with docker compose down -v.

Add a team, a person, an agent, and a goal story

The examples below assume the stack is running. Each POST returns the created row(s). IDs are server-generated UUIDs by default; you can also supply your own string ID (the schema examples like p-1, t-1 are valid). Pass Prefer: return=representation if you want the inserted row(s) echoed back.

Create a person (with a client-supplied ID):

curl -sX POST http://localhost:2626/actors \
  -H 'Content-Type: application/json' \
  -H 'Prefer: return=representation' \
  -d '{
    "id": "p-1",
    "actor_type": "person",
    "name": "Quinn Reed",
    "role": "Product Manager",
    "timezone": "America/Chicago"
  }'

Create an agent (server picks the ID):

curl -sX POST http://localhost:2626/actors \
  -H 'Content-Type: application/json' \
  -H 'Prefer: return=representation' \
  -d '{
    "actor_type": "agent",
    "name": "Research Bot",
    "role": "Compiles ongoing market research"
  }'

Create a team referencing both actors:

curl -sX POST http://localhost:2626/teams \
  -H 'Content-Type: application/json' \
  -H 'Prefer: return=representation' \
  -d '{
    "id": "t-1",
    "name": "Product",
    "description": "Shape and maintain the core product",
    "member_ids": ["p-1", "<agent-id>"]
  }'

Create a goal story with a nested timeframe:

curl -sX POST http://localhost:2626/goal_stories \
  -H 'Content-Type: application/json' \
  -H 'Prefer: return=representation' \
  -d '{
    "id": "g-1",
    "title": "Improve new customer onboarding experience",
    "description": "Reduce time-to-value from 10 days to under 3.",
    "team_ids": ["t-1"],
    "actor_ids": ["p-1", "<agent-id>"],
    "timeframe": { "start": "2026-01-06", "end": "2026-03-31" }
  }'

What's next

From here, the loops run:

• Ground-Level Loop -- POST /team_checkins to record what an actor is working on, finished, and blocked on.
• Big-Picture Loop -- POST /goal_story_updates to publish narrative status on a goal story.

Every create or substantive edit on a check-in or goal story update produces a coordination_event automatically -- no separate write needed. The events form an audit trail: an original event at creation, plus one per meaningful edit. Query the feed at GET /coordination_events.

Visit the Continuous Coordination skills repo to use AI assistants to help participate in the loops and for autonomous agent participation.

In production, those check-ins and updates are typically authored by AI agents using the skills repo -- drafted from work signals (commits, calendar, docs) and posted to this server. Humans can also write them directly.

API

PostgREST exposes its auto-generated OpenAPI spec at the root path. The interactive Swagger UI at http://localhost:2627/ reads that spec and lets you exercise every endpoint.

URL conventions follow PostgREST native syntax:

Operation	URL
List	GET /actors
Filter	GET /team_checkins?team_id=eq.t-1&date=gte.2026-01-01
Sort, page	GET /goal_stories?order=created_at.desc&limit=20&offset=20
Read one	GET /actors?id=eq.p-1
Create	POST /actors
Update	PATCH /actors?id=eq.p-1
Delete	DELETE /actors?id=eq.p-1

Full filter operator list (eq, neq, gt, gte, lt, lte, like, ilike, in, is, cs/cd for arrays, etc.) is in the PostgREST docs.

Schema version

This release implements Continuous Coordination schema 1.0.0. The server's SQL schema mirrors the JSON Schemas in the schema repo -- a major schema bump triggers a major server bump. No silent multi-version support.

Configuration

Configured via environment variables on the compose stack.

Variable	Default	Description
POSTGRES_PASSWORD	changeme	Password for the authenticator Postgres role. Override for anything but local play.

PostgREST and Postgres expose many more knobs (custom schemas, connection pool, JWT secrets if you add auth) -- see the PostgREST configuration reference. Edit docker-compose.yml to set them.

Persisting data: the postgres-data named volume keeps the database across restarts. docker compose down -v wipes it.

Development

The server is mostly SQL. To change the API, edit db/init/01_schema.sql -- add columns, constraints, views, or triggers, then docker compose down -v && docker compose up -d to rebuild from a clean slate.

Project layout:

db/init/01_schema.sql   tables, views, triggers, role grants
db/seed.sql             optional demo data
bin/seed                loads seed.sql into the running stack
viewer/index.html       static read-only data viewer (served by nginx)
docker-compose.yml      Postgres + PostgREST + Swagger UI + Viewer

Ecosystem

• Schema -- JSON Schema definitions for the six entities. Source of truth for shapes.
• Skills -- skills for agents to use to draft team check-ins and goal story updates and post them to a server like this one.
• continuouscoordination.org -- the methodology.
• Steady -- commercial Continuous Coordination platform.

License

MIT. The schema this server implements is published under CC BY-SA 4.0 in its own repo.