The open-source organizational intelligence and governance layer.
Jamot Core keeps humans and AI agents aligned on what an organization is actually trying to do. It turns conversations and work into verified knowledge, reflects on that knowledge, and evolves a versioned, human-governed Living Blueprint of the organization's purpose, goals, priorities, and constraints.
AI proposes. Humans govern. The organization learns.
Companies are accumulating AI tools faster than they can organize themselves around them. Knowledge lives in Slack, email, Notion, GitHub, meetings, and people's heads. AI agents can access pieces of it — but there is rarely a single, trusted representation of:
- what the organization is trying to achieve,
- what it currently believes,
- what decisions have been made,
- what constraints exist,
- who has authority,
- and what has changed.
As agents move from assistants to autonomous actors, this fragmentation becomes dangerous. Agents don't just need more data — they need organizational context. Jamot Core is the trusted state and governance layer that provides it.
Jamot Core is a small, deliberately boring core that owns exactly one thing: trusted organizational state.
| Capability | What it means |
|---|---|
| Living Blueprint | The organization's current operating state — purpose, principles, goals, priorities, initiatives, roles, constraints, metrics, policies — as immutable, versioned revisions. One active revision per org. |
| Verified knowledge | Durable facts, decisions, problems, discoveries, insights, and outcomes — extracted from activity, verified by humans, with full provenance and vector + full-text hybrid search. |
| Governance | Every Blueprint change is a proposal with evidence, risks, alternatives, and rollback — reviewed and approved by humans. No autonomous Blueprint mutation, ever. |
| Audit trail | Append-only event log with correlation chains: how the organization got to its current state, step by step. |
AI can observe, extract, summarize, reflect, and propose. AI cannot change the Blueprint, approve its own proposals, or modify governance rules.
Human conversation or organizational activity
│
▼
Knowledge Candidate
│
▼
Human Verification ( <30s )
│
▼
Verified Knowledge
│
▼
Reflection
│
▼
Blueprint Change Proposal
│
▼
Human Review
Approve / Reject / Edit
│
▼
New Blueprint Revision
│
▼
Decision / Action
│
▼
Outcome Recorded ──────► Future Reflection
Modular monolith. Three runtime services, one database, no distributed-systems tax.
┌──────────────────────┐
│ Jamot Studio │ Next.js / React / TypeScript
└──────────┬───────────┘
│ HTTPS REST
▼
┌──────────────────────┐
│ Jamot Core API │ FastAPI — Blueprint, Knowledge, Governance,
│ │ Decisions, Auth, Audit, MCP adapter
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ PostgreSQL 16 │ + pgvector (HNSW)
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Jamot Worker │ Python — extraction, reflection, proposal
└──────────┬───────────┘ generation (Postgres-as-queue, SKIP LOCKED)
│
▼
Model Provider Any OpenAI-compatible endpoint
No Redis, no Kafka, no Neo4j, no LangGraph required. Everything replaceable later via provider interfaces.
These are the properties that keep the system small and correct:
- One active Blueprint revision per org — enforced by a partial unique index, not by convention
- Immutable history — revisions are append-only; rollback means a new revision, never a mutation
- Optimistic governance concurrency — every change references a base revision; stale base →
409, not a silent overwrite - Append-only event log — UPDATE/DELETE blocked at the database level; full causal chains via
correlation_id - Org isolation everywhere —
org_iddenormalized into every table, injected from auth context, never from the client - Agents can never self-approve — proposer ≠ sole approver, enforced in the service layer, over both REST and MCP
- Versioned embeddings — dimension changes are a migration with re-embedding jobs, never a silent index corruption
REST — /api/v1 for Studio, admin tools, and external apps.
MCP — /mcp for AI agents and MCP-compatible hosts:
get_blueprint search_knowledge create_knowledge_candidate
get_blueprint_revision get_knowledge create_proposal
get_current_priorities get_knowledge_provenance get_proposal
get_decision
Agents authenticate with revocable API keys and inherit the same RBAC pipeline as humans. They can read the Blueprint and submit proposals — they can never mutate state directly.
Model providers — any OpenAI-compatible HTTP endpoint (MODEL_BASE_URL / MODEL_API_KEY / MODEL_NAME). Swap OpenAI for vLLM or a self-hosted SLM with zero code changes. Embeddings are independently configurable and versioned.
| Layer | Choice |
|---|---|
| Backend | Python 3.12+, FastAPI, SQLAlchemy 2 (async), Pydantic v2, Alembic |
| Database | PostgreSQL 16+, pgvector 0.8+ (HNSW), UUIDv7 keys |
| Frontend | Next.js 15+, React 19+, TypeScript |
| Worker | Python, Postgres-as-queue (FOR UPDATE SKIP LOCKED, leases, backoff, reaper) |
| Auth | Argon2id passwords, JWT (15m) + rotating refresh tokens (7d), agent API keys |
| Deploy | Docker, docker compose locally, Render Blueprint (render.yaml) in prod |
Pre-MVP. The full system specification — data model, governance rules, worker semantics, API surface, testing plan, and the pilot experiment's pass/fail metrics — lives in SPEC.md. The spec is the contract; code follows it.
The MVP exists to answer one question with 1–3 real founder-led organizations:
Can an organization measurably improve coordination by turning conversations into verified knowledge and evolving a Living Blueprint under human governance?
Available once Phase 1–2 of the spec land.
cp .env.example .env
docker compose up --build- Studio → http://localhost:3000
- API → http://localhost:8000 (docs at
/docs) - MCP → http://localhost:8000/mcp
apps/
core/ FastAPI service — REST API, MCP adapter, domain models
worker/ Python worker — extraction, reflection, proposal generation
studio/ Next.js app — overview, blueprint, knowledge, submit, proposals
packages/
schemas/ Shared Pydantic schemas (blueprint, knowledge, proposals, events)
tests/ unit, api, governance race tests, worker concurrency, e2e
SPEC.md The full system specification (read this first)
render.yaml Render deployment blueprint
docker-compose.yml
The project is pre-MVP; the most useful contributions right now are review feedback on SPEC.md — invariants, governance rules, and the pilot success metrics (§2.1). Issues and PRs welcome once the scaffold lands.
Apache 2.0 © 2026 Jamot