PyLLM

Running DataHub applications learn, validate, retain, and replay missing behavior—without a source edit, redeploy, or repeated agent call.

Comment

Frozen Release, Living Semantics

Agents write the application. PyLLM lets the running application retain new behavior after the agents finish.

PyLLM is a framework for human- and agent-authored DataHub applications with deliberately missing runtime behavior. When an unfamiliar case appears, ordinary execution fails safely. During an explicit pyllm learn episode, PyLLM gathers authoritative metadata for exact DataHub assets, asks the user's installed Codex or Claude agent for one typed handler, validates it with trusted application policy, and atomically activates readable Python.

Future matching cases run locally without an agent, DataHub, credentials, source edit, build, deployment, or restart.

Why DataHub is essential

The payment compatibility gateway proves a problem that payload inspection alone cannot solve. Atlas-v2 and Boreal-v1 expose the same JSON shape and primitive types, but their amount and settlement-time semantics differ. A shape-only adapter would silently corrupt one producer.

PyLLM scopes learning by:

  • Exact source asset
  • Source contract hash
  • Target contract hash
  • Value-free payload shape

DataHub Core stores the contracts and lineage. The official DataHub MCP Server supplies bounded schema and catalog evidence during learning. After trusted validation, PyLLM writes an idempotent linked DataHub Decision receipt so the next person or agent inherits what the running application learned.

What the demo proves

  1. A frozen localhost gateway starts without Codex, Claude, or DataHub MCP in its runtime path.
  2. Trusted Format A succeeds; three unfamiliar Atlas events enter a durable pending queue.
  3. One explicitly authorized learning process reads live Atlas and canonical contracts through DataHub MCP.
  4. Trusted validation accepts a restricted handler and PyLLM atomically activates readable Python.
  5. The already-running gateway—with the same PID and authored release hash—drains the backlog.
  6. One hundred varied Atlas events execute locally with no new learning audit or external contact.
  7. Same-shape Boreal remains unlearned because its DataHub semantics differ.
  8. A negative Atlas record is quarantined locally without repair, relearning, or source change.

Measured live result

  • 1 authorized learning audit
  • 1 published, linked DataHub Decision receipt
  • 3 pending Atlas events recovered
  • 100 future Atlas executions without audit growth
  • 0 gateway restarts
  • Boreal safely isolated despite matching Atlas's physical shape
  • Negative Atlas input rejected without changing generated source

Technical execution

PyLLM uses Python 3.13/3.14, DataHub OSS/Core, the official DataHub MCP Server, installed Codex or Claude Code agents, immutable snapshots, direct case-hash dispatch, a restricted AST evaluator, per-behavior process locks, atomic source replacement, a manifest-hash evaluator cache for hot activation, and value-free audit records.

Generated modules return typed values only. They are parsed and interpreted—never imported or passed to exec. DataHub metadata guides learning but is not available as a runtime handler variable. Ordinary replay starts neither an agent nor MCP.

The verified repository run passed 125 core tests and 45 demo tests, strict Ruff and mypy checks, both package builds, privacy/credential scans, and more than 90% branch coverage in both projects.

Judge-facing evidence

Boundary

The included gateway is a localhost demonstration using synthetic records, not a production payment processor. PyLLM's restricted evaluator is a strong boundary against malformed generated output, not an OS-level hostile-code sandbox.

Built With

  • claude-code
  • codex-cli
  • datahub-mcp-server
  • datahub-oss
  • python
  • uv
Share this project:

Updates