keel-context 0.1.0__tar.gz

keel_context-0.1.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,24 @@
+name: Bug report
+description: The core, the CLI or a shipped cartridge does not behave as documented.
+labels: [bug]
+body:
+  - type: textarea
+    id: what
+    attributes:
+      label: What happened
+      description: What you did, what you expected, what you got. A failing test or a `keel` command is ideal.
+    validations:
+      required: true
+  - type: textarea
+    id: events
+    attributes:
+      label: Events to reproduce
+      description: The smallest `.jsonl` stream (or table rows) that triggers it. Strip anything confidential.
+      render: json
+  - type: input
+    id: version
+    attributes:
+      label: Keel version and Python version
+      placeholder: keel 0.0.1, Python 3.12
+    validations:
+      required: true

keel_context-0.1.0/.github/ISSUE_TEMPLATE/cartridge_proposal.yml

@@ -0,0 +1,23 @@
+name: Cartridge proposal
+description: Propose a new vertical, or report that writing one needed a change under keel/.
+labels: [cartridge]
+body:
+  - type: input
+    id: vertical
+    attributes:
+      label: Vertical
+      placeholder: clinics, last-mile logistics, property management
+    validations:
+      required: true
+  - type: textarea
+    id: ontology
+    attributes:
+      label: Entities, relations and the three most important event types
+      description: A sketch is enough. See cartridges/fleet/cartridge.yaml for the shape.
+    validations:
+      required: true
+  - type: textarea
+    id: core
+    attributes:
+      label: Did the core get in the way?
+      description: Anything under keel/ you had to change or wished existed. This is the most valuable part.

keel_context-0.1.0/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,11 @@
+## What
+
+## Why
+
+## Checklist
+
+- [ ] `uv run pytest` and `uv run ruff check .` pass
+- [ ] `cartridges/fleet` and `cartridges/crm` still validate without edits
+- [ ] Core change: a test in `tests/` covers it. Cartridge change: events in `examples/events/` and assertions.
+- [ ] Nothing under `keel/` names an entity kind, relation, predicate, rule or event type
+- [ ] If `examples/agent_minimal.py` output changed, the reason is in this description

keel_context-0.1.0/.github/workflows/docs.yml

@@ -0,0 +1,27 @@
+name: docs
+
+on:
+  push:
+    branches: [master]
+    paths:
+      - docs/**
+      - mkdocs.yml
+      - ROADMAP.md
+      - CONTRIBUTING.md
+      - .github/workflows/docs.yml
+  workflow_dispatch:
+
+permissions:
+  contents: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: |
+          git config user.name github-actions[bot]
+          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
+      - uses: astral-sh/setup-uv@v5
+      - run: uv sync --extra docs
+      - run: uv run mkdocs gh-deploy --force

keel_context-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,26 @@
+name: release
+
+# Publishes to PyPI with trusted publishing (no token stored here) when a v* tag is pushed.
+# One-time setup on PyPI: add a pending publisher for project keel-context, owner angelkurten,
+# repository keel, workflow release.yml, environment pypi.
+on:
+  push:
+    tags: ["v*"]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  pypi:
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+      - run: uv sync --extra dev
+      - run: uv run pytest -q
+      - run: uv build
+      - uses: pypa/gh-action-pypi-publish@release/v1

keel_context-0.1.0/.gitignore

@@ -0,0 +1,9 @@
+__pycache__/
+*.pyc
+.venv/
+.pytest_cache/
+.ruff_cache/
+dist/
+*.egg-info/
+.env
+site/

keel_context-0.1.0/CLAUDE.md

@@ -0,0 +1,81 @@
+# Keel — project spec for coding agents
+
+Read this before changing anything. It says what Keel is, what it is not, and the rules that keep the core generic. `ROADMAP.md` says what comes next.
+
+## What Keel is
+
+A context layer for AI agents inside vertical SaaS products. Domain events from the SaaS go in; a bitemporal context graph **per end-customer** (the tenant of the tenant) comes out; every agent reads and writes it through the same five tools.
+
+The domain is declared once in a **cartridge** (YAML + a few ten-line handlers). The core knows nothing about any domain.
+
+Positioning, in one line: *stop rebuilding the pipeline for every agent.* "Shared memory for agents" is the consequence, never the headline.
+
+## What Keel is not
+
+- Not an agent framework. Agents live in LangGraph, ADK, the Claude SDK, wherever. Keel is what they consult.
+- Not a document/RAG memory. We ingest structured events with time, not text. Ingestion is deterministic. No LLM in the ingest path (see Open decisions).
+- Not a copy of the SaaS's database. The graph holds pointers, semantics and earned memory.
+- Not a single global memory. Memory has scopes and nothing is promoted by accident.
+
+## Architecture
+
+```
+sources (Postgres table/CDC, webhooks, Kafka later)
+   -> Event envelope (keel/envelope.py)        tenant, type, subject, occurred_at, recorded_at, source, payload
+   -> Ingestor (keel/ingest.py)                 reads an adapter, dispatches by event.type
+   -> HandlerRegistry (keel/handlers.py)        cartridge handlers map payload -> store primitives
+   -> Store (keel/store/)                       bitemporal: entities, relations, facts; one subgraph per tenant (memory or sqlite)
+   -> Tools (keel/tools.py)                     context / history / search / annotate / related
+   -> MCP server (keel/mcp_server.py)           optional; exposes the same five tools
+cartridges/<name>/cartridge.yaml + handlers.py  ontology, event catalog, rules, memory policy, handlers
+```
+
+Store primitives are the only write path: `upsert_entity`, `link`, `unlink`, `open_fact`, `close_fact`. `open_fact` closes the previous open fact on the same predicate; nothing is overwritten.
+
+## Design rules (enforce these in review)
+
+1. **Events are the truth.** The log is append-only; the graph is derived and must be rebuildable with `Ingestor.replay(tenant)`. Any state that cannot be rebuilt from events is a bug.
+2. **Pointers, not copies.** An entity carries `ref` to the row in the system of record and the few attributes a tool needs to label it. If a PR copies a whole row or table into the graph, reject it.
+3. **Explicit time, bitemporal.** `valid_from`/`valid_to` = world time. `recorded_at` = when Keel learned it. Facts close; they are never mutated or deleted by handlers. "The tire was critical on Oct 3" and "the tire is critical" are different queries and both must work.
+4. **Provenance on every fact.** `source`, `evidence` (event id, row ref, photo), and `corrected_by` when a human or agent corrected it.
+5. **Scopes, not a flat store.** `global` > `tenant` > `task` > `agent`. Policy (TTL, evidence requirement) is enforced in `Tools.annotate` via `MemoryPolicy`, never trusted to the calling agent. Promotion to a wider scope is an explicit `annotate` with evidence.
+6. **The core is domain-agnostic.** No entity kind, relation name, predicate, rule or event type appears anywhere under `keel/`. The acceptance test for any core change: both `cartridges/fleet` and `cartridges/crm` still pass without edits. Adding a third cartridge must require zero changes under `keel/`.
+7. **Five tools, and only five.** New capabilities go into the semantics of these five (richer `context`, filters on `history`) before anyone adds a sixth. The tool names and signatures are part of the public standard.
+8. **One subgraph per tenant.** Every store call takes `tenant` first. Cross-tenant reads do not exist. A tool instance is bound to one tenant.
+9. **Handlers are small.** A handler maps one payload to primitives in ~10 lines. Business logic (what "critical" means) lives in `rules`, read by tools, not in handlers and not in agents.
+10. **Deterministic ingest.** No network calls, no LLM calls, no randomness in the ingest path. Replay must produce an identical graph.
+
+## Conventions
+
+- Python 3.10+, `uv`, `pytest`, `ruff` (line length 100). Type hints everywhere; pydantic for the envelope only, dataclasses in the store.
+- Subject keys are `<kind>:<id>` strings. Event types are dotted lowercase: `inspection.created`.
+- Datetimes are timezone-aware UTC. Naive datetimes are rejected at the envelope.
+- Public surface: `keel/__init__.py` exports. Anything else is internal and may change.
+- All user-facing text (README, docs, CLI help, errors) is in English. Commit messages in English.
+- Tests: every core change adds or updates a test in `tests/`; cartridge changes add events to `examples/events/*.jsonl` and assertions in `tests/test_core.py`.
+
+## How to verify a change
+
+```bash
+uv sync --extra dev
+uv run pytest
+uv run keel validate cartridges/fleet && uv run keel validate cartridges/crm
+uv run python examples/agent_minimal.py
+```
+
+If `examples/agent_minimal.py` output changes, say why in the PR.
+
+## Open decisions (do not resolve silently)
+
+- **Durable store.** Decided 2026-10-14: pluggable by design, never a core change. `Store` protocol (`keel/store/base.py`), `MemoryStore` as reference, `SqliteStore` as the default durable one, and a conformance suite any store can run (`KEEL_STORE=pkg.module:factory uv run pytest tests/test_store.py`). Graphiti or Postgres would be third implementations; if Graphiti forces an LLM in the ingest path, use only its graph store and keep our deterministic ingest.
+- **Consolidation/decay.** Expiry is shipped (`expires_at`, `store.expire`, `keel expire`). Summarizing old episodic facts into durable ones is deliberately left open (2026-10-14) until a pilot brings a real case; the leading candidate is a deterministic job, never an LLM in the core.
+- **Multi-cartridge tenants.** One tenant, one cartridge for now. Composing cartridges is a later decision.
+- **Pricing unit** (hosted): events ingested per month. Not a code concern yet, but metering must be possible from the log.
+
+## Things to never do
+
+- Never add a dependency to the core for one cartridge's convenience.
+- Never let a tool return facts from another tenant.
+- Never delete or mutate a fact from a handler. Close it.
+- Never read `event.payload` in `keel/`. Only handlers do. One exception: `Cartridge.check_event` (behind `keel validate --events`) compares payload keys and types with the catalog; it never reads values.
+- Never write generic placeholders (`TBD`, `n/a`) into cartridge YAML; leave the key out.

keel_context-0.1.0/CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Contributing to Keel
+
+Keel is built in the open, part-time. Small, focused pull requests land fastest.
+
+## Set up
+
+```bash
+uv sync --extra dev
+uv run pytest
+uv run keel validate cartridges/fleet --events examples/events/fleet.jsonl && uv run keel validate cartridges/crm --events examples/events/crm.jsonl && uv run keel validate cartridges/finance --events examples/events/finance.jsonl && uv run keel validate cartridges/clinics --events examples/events/clinics.jsonl
+```
+
+## What we are looking for
+
+- **Cartridges.** The best contribution. A new vertical (clinics, logistics, property management, ...) in `cartridges/<name>/` with `cartridge.yaml`, `handlers.py`, a sample stream in `examples/events/<name>.jsonl` and a test in `tests/`. It must pass `keel validate` and require zero changes under `keel/`. If it does need a core change, open an issue first: that is a bug in the core, and we want to fix it generically.
+- **Adapters.** Sources that yield `Event`s (see `keel/adapters/`). An adapter never reads a payload.
+- **Bug reports with a failing test.** The fastest way to get something fixed.
+
+## Rules the review enforces
+
+`CLAUDE.md` is the spec and `docs/SPEC.md` is the normative contract. The short version:
+
+1. No domain names under `keel/`: no entity kind, relation, predicate, rule or event type.
+2. Pointers, not copies. Never copy a row or a table into the graph.
+3. Facts close. Handlers never mutate or delete them.
+4. Five tools. New capability goes into the semantics of the existing five.
+5. Deterministic ingest: no network, no LLM, no randomness.
+6. Every core change comes with a test. Every cartridge change comes with events and assertions.
+
+## Process
+
+- Open an issue before a large change. For a cartridge or a small fix, a pull request is fine.
+- Run `uv run ruff check .` and `uv run pytest` before pushing.
+- Commit messages and all user-facing text in English.
+- If `examples/agent_minimal.py` output changes, say why in the pull request.
+
+By contributing you agree that your contributions are licensed under the Apache License 2.0.
+
+## Your own store
+
+The core talks to a `Store` protocol (`keel/store/base.py`); `MemoryStore` is the reference and `SqliteStore` the default durable one. A third store (Postgres, Graphiti, anything) is a separate package, never a core change. Run the conformance suite against it:
+
+```bash
+KEEL_STORE=your_pkg.module:factory uv run pytest tests/test_store.py
+```
+
+`factory` is a zero-argument callable or class that returns a fresh, empty store.
+
+## Releasing
+
+Bump `version` in `pyproject.toml` and `__version__` in `keel/__init__.py`, update the roadmap, then:
+
+```bash
+git tag -a vX.Y.Z -m "keel-context X.Y.Z" && git push origin vX.Y.Z
+gh release create vX.Y.Z --title "X.Y.Z" --notes-file notes.md
+```
+
+The tag triggers `.github/workflows/release.yml`, which runs the tests, builds and publishes `keel-context` to PyPI through trusted publishing (one-time setup on PyPI: pending publisher for project `keel-context`, owner `angelkurten`, repository `keel`, workflow `release.yml`, environment `pypi`).

keel_context-0.1.0/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

keel_context-0.1.0/NOTICE

@@ -0,0 +1,4 @@
+Keel
+Copyright 2026 Angel Kürten / Kubbo Software, Inc.
+
+Licensed under the Apache License, Version 2.0. See LICENSE.

keel_context-0.1.0/PKG-INFO

@@ -0,0 +1,178 @@
+Metadata-Version: 2.5
+Name: keel-context
+Version: 0.1.0
+Summary: Context layer for AI agents in vertical SaaS: domain events in, a per-tenant bitemporal context graph out, shared by every agent through five MCP tools.
+Project-URL: Homepage, https://github.com/angelkurten/keel
+Project-URL: Documentation, https://angelkurten.github.io/keel/
+Author-email: Angel Kürten <angel@angelkurten.com>
+License: Apache-2.0
+License-File: LICENSE
+License-File: NOTICE
+Keywords: agents,bitemporal,context,event-driven,knowledge-graph,mcp
+Classifier: Development Status :: 3 - Alpha
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Libraries
+Requires-Python: >=3.10
+Requires-Dist: pydantic>=2.6
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: typer>=0.12
+Provides-Extra: dev
+Requires-Dist: fastapi>=0.110; extra == 'dev'
+Requires-Dist: httpx>=0.27; extra == 'dev'
+Requires-Dist: mcp>=1.2; extra == 'dev'
+Requires-Dist: pytest>=8.0; extra == 'dev'
+Requires-Dist: ruff>=0.5; extra == 'dev'
+Provides-Extra: docs
+Requires-Dist: mkdocs-material>=9.5; extra == 'docs'
+Requires-Dist: mkdocs<2; extra == 'docs'
+Provides-Extra: graphiti
+Requires-Dist: graphiti-core>=0.5; extra == 'graphiti'
+Provides-Extra: mcp
+Requires-Dist: mcp>=1.2; extra == 'mcp'
+Provides-Extra: postgres
+Requires-Dist: psycopg[binary]>=3.1; extra == 'postgres'
+Provides-Extra: webhook
+Requires-Dist: fastapi>=0.110; extra == 'webhook'
+Requires-Dist: uvicorn>=0.27; extra == 'webhook'
+Description-Content-Type: text/markdown
+
+# Keel
+
+**Stop rebuilding the pipeline for every agent.**
+
+Docs: [angelkurten.github.io/keel](https://angelkurten.github.io/keel/) · Why: [We built four agents and four copies of our customer context](https://angelkurten.com/blog/keel-four-agents-four-copies-of-context)
+
+Keel is a context layer for AI agents inside vertical SaaS products. Domain events from your product go in; a bitemporal context graph per end-customer comes out; every agent you build reads and writes it through the same five MCP tools.
+
+You describe your vertical once, in a *cartridge* (ontology, event catalog, semantic rules, memory policies). Keel's core knows nothing about your domain. Your second agent connects in a day instead of weeks, because there is no second pipeline to write.
+
+> Status: 0.1.0, alpha. The MCP server (`keel serve`), the Postgres table adapter and the webhook adapter run against the in-memory store or the SQLite store (`--db keel.db`, stdlib, no server to run).
+
+![Terminal demo: validate the stream against the cartridge, ingest, ask for a tire's context with the rule's verdict, run an agent with no LLM](docs/demo.gif)
+
+## The problem
+
+Every new agent in a SaaS product repeats the same work: extract the customer's data, normalize it, decide what "critical" means, keep its own memory, expose its own tools to the model. Four agents, four copies of the customer's context, four definitions of "critical", four memories that never talk.
+
+Existing memory layers (Zep, Mem0, AgentCore Memory, Neo4j's MKG) ingest text and documents and model memory per user or per agent. None of them start from **domain events**, and none model the **tenant of the tenant**: the end-customer of a B2B SaaS.
+
+## How Keel is different
+
+1. **Cartridges.** A vertical is declared in YAML plus a few ten-line handlers. The core stays generic. Write a cartridge for fleets, clinics, logistics, or your own product.
+2. **Events in, not documents.** Keel ingests structured facts with time (Postgres tables, webhooks, Kafka later). Ingestion is deterministic and cheap. The graph is exact because it is born from events, not inferred from text.
+3. **Every fact carries its provenance.** Source, `valid_from`, `valid_to`, `recorded_at`, and who corrected it. Audit-ready by construction.
+4. **Tenant of the tenant.** One subgraph per end-customer, with its own permissions and expiry.
+
+## Five tools, any agent
+
+```
+context(subject, as_of?)                             -> what is true now, or at as_of: facts, relations, rules and their verdicts
+history(subject, since?, until?, predicate?, scope?)  -> what was true, and when we learned it
+search(text)                                         -> entities and facts matching text
+annotate(subject, predicate, value, scope, evidence)  -> an agent (or a human) writes what it learned
+related(subject, relation?)                          -> neighbors by relation type
+```
+
+Expose them over MCP (`keel serve`) and point any agent framework at them.
+
+## Quick start
+
+```bash
+uv sync --extra dev
+uv run keel validate cartridges/fleet --events examples/events/fleet.jsonl
+uv run keel ingest cartridges/fleet examples/events/fleet.jsonl
+uv run keel context cartridges/fleet examples/events/fleet.jsonl unit:MXK-4821
+```
+
+Then write your own cartridge: see [docs/first-cartridge.md](docs/first-cartridge.md) (20 minutes).
+
+In your own product it is a library: `uv add keel-context` (or `pip install keel-context`); the import is `import keel`.
+
+## Connect a real event stream
+
+Point an MCP client at the five tools:
+
+```bash
+uv sync --extra mcp
+uv run keel serve cartridges/fleet --tenant acme-logistics --events examples/events/fleet.jsonl
+```
+
+With Claude Code, one command registers it and the agent sees exactly five tools:
+
+```bash
+claude mcp add keel -- uv run --directory $PWD keel serve cartridges/fleet --tenant acme-logistics --events examples/events/fleet.jsonl
+```
+
+Codex CLI (OpenAI) works the same way from `~/.codex/config.toml`; the four read tools are annotated read-only, so it runs them without prompting. Both clients answered the same questions through the same five tools: see [connect](docs/connect.md#serve-the-tools-over-mcp).
+
+Poll an outbox table in your Postgres (a cursor file makes restarts resume, not re-ingest):
+
+```python
+import psycopg
+from keel.adapters.postgres import PostgresTableAdapter
+
+adapter = PostgresTableAdapter(lambda: psycopg.connect(DSN), table="keel_events", cursor_path=".keel/cursor")
+ingestor = Ingestor(cartridge, SqliteStore("keel.db"))  # durable; MemoryStore() for a throwaway graph
+ingestor.ingest(adapter.follow(interval=5))
+```
+
+Or receive envelopes over HTTP (`uv sync --extra webhook`):
+
+```python
+from keel.adapters.webhook import build_app
+
+app = build_app(ingestor, token="shared-secret")  # POST /events, Authorization: Bearer <token>
+```
+
+The table shape and the envelope fields are in `keel/adapters/postgres.py` and `keel/envelope.py`. `keel export <tenant> --db keel.db` writes one tenant's whole audit trail as JSONL, closed facts and provenance included.
+
+## Architecture
+
+```
+  your SaaS (Postgres)   webhooks   Kafka / SQS (later)
+            \               |            /
+             v              v           v
+   +-------------------------------------------------+      +------------------+
+   |  event envelope: tenant, type, subject, time     |      |  cartridge       |
+   |  ingestor + handler registry                     | <--- |  ontology        |
+   |  bitemporal context graph, one subgraph/tenant   |      |  event catalog   |
+   |  memory scopes: global / tenant / task / agent   |      |  handlers        |
+   |  five MCP tools                                   |      |  semantic rules  |
+   +-------------------------------------------------+      |  memory policies |
+            |              |             |                   +------------------+
+         agent A        agent B       agent N (no pipeline)
+```
+
+Design rules the core enforces:
+
+- **Events are the truth.** An append-only log; the graph is derived and can be replayed.
+- **Pointers, not copies.** The graph holds references to your rows, the semantics, and earned memory. Never a copy of your tables.
+- **Explicit time.** Facts close, they are not overwritten.
+- **Scopes, not a flat store.** Nothing is promoted to a wider scope by accident.
+
+## Repository layout
+
+```
+keel/            core: envelope, handlers, store, scopes, cartridge loader, ingest, tools, cli
+cartridges/      fleet (reference), crm, finance and clinics: four domains, one core, no core change between them
+examples/        sample event streams and a minimal agent
+docs/            site sources (mkdocs.yml at the root): first-cartridge, connect, SPEC
+tests/
+```
+
+## Roadmap
+
+- [x] Event envelope and handler registry
+- [x] In-memory bitemporal store
+- [x] Memory scopes with expiry
+- [x] Five tools as plain functions
+- [x] MCP server (`keel serve`)
+- [x] Durable store: SQLite (Graphiti still planned for graph-native queries)
+- [x] Postgres (table + polling) and webhook adapters
+- [ ] Consolidation and decay jobs
+- [ ] Cartridge catalog
+
+## License
+
+Apache 2.0. The event envelope, the cartridge format and the five tools are the standard; they will always be free.