Weekly progress

Week 2026-W44 2026-10-26 – 2026-11-01, in progress

Versions: 0.104.0 → 0.107.0

5 commits so far, all on 2026-10-26.

Summary

Hooks and naming. Hosts can now route a trained model's prompts to their own inference code, exporting was renamed deploying, recall became query everywhere, and an Auth hook lets a host's API keys identify users. Three of the four releases are breaking.

Highlights

• Inference hooks for trained models (0.104.0): ServeOptions.TrainedModelInferenceHooks binds a hook to a trained model by name; prompts to that model go to the hook instead of the sidecar (Modal). The infer answer has a hook field, GET /v1/gb/training/inference-hooks lists them, and the admin UI says when a model does not run on Modal.
• Auth hook (0.107.0): with ServeOptions.Auth set, user routes (remember, query, datasets, timeseries, ontologies) need Authorization: Bearer <key>; the hook maps the key to a user ID, the request acts as that user, and a missing or rejected key is a 401. Without the hook nothing changes. See docs/hooks.md and docs/identity.md.
• Python client: reads the API key from GLIGABAO_API_KEY (or Client(api_key=...)) and sends it as the bearer token; user_id is no longer a parameter of remember, query or attach_timeseries. New Client.query().

Breaking changes

• recall is now query (0.106.0): POST /v1/gb/query (and /v1/gb/eval/query), the memory_query package, query.completed / query.failed events, inference type/stage query, eval reasoning key, and the eval DB columns query_calls and query_cost_usd. The eval database must be recreated. Older changelog entries keep the old name.
• Exporting is now deploying (0.105.0): TrainedModelExporters is TrainedModelDeployers, endpoints are /v1/gb/training/models/{id}/deployments and /v1/gb/training/deployers, the config key is trained_model_deploy_dir (flag --trained-model-deploy-dir), events are training.model_deploy.*, and the table is gb_trained_model_deployments. The admin UI says Deploy. No migration: recreate the DB or rename the table by hand.
• Python client: user_id removed from remember, query and attach_timeseries (0.107.0).

Releases

Week 2026-W43 2026-10-19 – 2026-10-25

Versions: 0.51.0 → 0.103.0

88 commits.

Summary

Two themes. The first half of the week was an overhaul of evals and training checks: evals now have cases and share one data model, and the training-data audit was split out as its own package. The second half opened gligabao up to programs that embed it: trained-model exporters, admin UI extensions, a public CLI package, content directories in the config, and gligabao.Mount for hosting the handlers on an existing HTTP server. Several renames and schema changes are breaking.

Highlights

Evals and audits

• Experiments for trained models (0.51.0): trained-model evals can be run as named experiments, each run linked to its eval and trained model.
• Eval vocabulary settled (0.56.0): an eval case is one input/output to check, an eval is a set of cases (the "suite" concept is gone), a run executes cases, an experiment is a named series of runs. Training evals have one case result per example, and judged cases pass at judge score >= 4. Admin API, schema, runner flags (-eval, -list-evals) and docs follow.
• Real evals for trained models (0.61.0): POST /v1/gb/training/models/{id}/evals takes an eval name and cases, not just the model's own training dataset. ./run_evals.sh -t training -model ID does the same from the command line and stores the run.
• Training data audits (0.58.0): asking a model the questions from its own training data is an audit, not an eval. It shows whether training took and which examples keep failing. Audits first lived next to evals, then moved to a new, separate internal/training_audits package (0.77.0–0.80.0), and the admin UI got an audit modal (0.81.0). Cases scored 0/5 are shown in magenta.
• Evals rewrite (evals_neo) (0.71.0–0.88.0): a new data model (per-type metadata tables for case defs, case runs and eval runs), DB functions, runners, and the admin UI and training evals switched over; the old internal/evals was removed, then evals_neo took over its name and gb_neo_* tables became gb_*.
• Evals definitions moved to bin/ and are read from disk; eval files are {name, cases}.

Training and admin UI

• Gemma 4 31B (0.95.0): third model size, 31b, in the training API and size picker.
• Cheaper inference: GPU inference containers now stay up 60 s after the last request instead of 300 (0.89.0).
• More robust training event delivery (Modal Dict -> SSE -> Go monitor -> UI).
• serve --training / training = true gates the training handlers.
• Admin UI: clicking a trained model opens an actions box (info, prompt, eval, audit, later export); prompt and info have their own dialogs; dataset upload in a modal; help modals for models and datasets; Cancel renamed to Stop; audit container indicator.

Embedding gligabao in other programs

• Trained-model exporters (0.96.0, 0.101.0, 0.103.0): a hook, ServeOptions.TrainedModelExporters, lets a host program take a model's weights. POST /v1/gb/training/models/{id}/exports fetches the files from the sidecar (verified by size and sha256) and calls the named exporter. The admin UI has an Export dialog and an Exporters block, GET /v1/gb/training/exporters lists them, and exporters can report progress with req.Update.
• Admin UI extensions (0.97.0): hosts can add views, buttons and blocks with plain JavaScript through ServeOptions.AdminExtensions, with named slots and CSS variables. See docs/admin-extensions.md.
• Public CLI package (0.98.0): github.com/deepblue-phoenix/gligabao/cli gives embedding programs serve, version, --config and all serve flags through cli.New.
• Content directories as lists (0.99.0, 0.100.0): datasets_training_dirs, evals_training_dirs, evals_knowledge_dirs and ontology_dirs in gligabao.toml (first directory wins), plus trained_model_export_dir. Ontologies load by file name from ontology_dirs.
• gligabao.Mount (0.102.0): register all handlers under /v1/gb/ on a host's *http.ServeMux instead of listening on a port.
• serve no longer prints usage on runtime errors and force-closes connections if graceful shutdown times out.

Breaking changes

• Eval renames (0.56.0, 0.68.0–0.70.0): suite is eval in the eval DB, admin API and Go types; runner flags are -evals, -eval, -list-evals and run_evals.sh -e; tables were renamed (gb_experiments_defs, gb_experiment_case_runs, ...).
• 0.61.0 and 0.88.0: the eval database must be recreated; old eval and audit tables are no longer created. scheme and finetune_dataset are gone from the evals API (use an audit).
• Training API now works with one database; training.Database and training.Pick are gone (0.67.0).
• ServeOptions.TrainingDatasetDir and TrainingEvalDir became lists, TrainingDatasetDirs and TrainingEvalDirs (0.100.0).
• Nothing is migrated; leftover schema migration code was removed. The unused gb_items table was dropped (0.66.0).

Other changes

• Large internal reorganisation: evals into internal/evals, training code into internal/training and internal/training/db, internal/memory/memory_ontology, and jev/buildinfo/config/sidecar/server into internal/sys. Config fields Eval and AdminUI renamed to EvalModeEnable and AdminUIenable (TOML keys unchanged).
• New docs: docs/listings/db-tables.md (every table) and go-structs.md (every struct), model exporting page, docs reorganised into evals/ and training/.
• run_tests.sh runs Go then Python tests, with -g/--go and -p/--py.
• The example ontology moved to bin/ontology; many stale comments and README paths fixed.

Releases

Selected releases (there were more, including patch releases; see CHANGELOG.md):

Week 2026-W42 2026-10-12 – 2026-10-18

Versions: 0.1.0 → 0.50.0

This was the biggest week (119 commits).

Summary

Three things happened. The memory pipeline grew a lot: images, long-text chunking, sessions, web search, timeseries, per-stage models and reasoning levels. The embedded admin UI became the main way to see what the server does. And a whole training side appeared: a Python sidecar that runs Gemma 4 fine-tuning and inference on Modal, with training jobs, trained models, and LLM-judged evals of those models. Versioning and CHANGELOG.md started on 10-13. Database schemas changed many times without migrations (see Breaking changes).

Highlights

Memory pipeline (remember / recall)

• Artifacts. What were "memories" are now artifacts, with provenance on entities and edges and a kind. Entities/edges are embedded into per-dataset vector stores, and remember finds candidate facts by entity similarity.
• Images (0.2.0). remember accepts an image (JPEG/PNG/GIF/WebP); a vision-LLM pipeline does OCR and classification. Files are kept on disk, deduplicated by SHA-256. The admin UI lets you paste an image to remember it.
• Sessions (0.5.0). Optional session_id on remember and recall labels a user/agent session and tracks which sessions discovered each entity and fact.
• Chunking (0.6.0) and chunk summaries (0.18.0). Long texts are split into token-sized overlapping chunks, each extracted, summarised and embedded on its own; chunks are child artifacts. Config: chunk_size, chunk_overlap_percent. A 60-person eval corpus checks it.
• Per-stage models and reasoning (0.7.0, 0.19.0). models picks the LLM for each stage (extract_graph, resolve_edges, extract_image, ...) and reasoning sets a thinking level per stage, in the API, Go and Python clients and evals.
• Jev classifier (0.8.0). An optional small "system 1" model (jev_api_key) classifies text as simple/medium/complex in expected entity count; logged and traced.
• Web search (0.9.0). web_search flag searches the web for key entities after storing; results become web_search artifacts.
• Timeseries (0.11.0–0.13.0, 0.15.0–0.17.0). remember accepts series, POST /v1/gb/timeseries stores and anchors them, embedding programs can register timeseries providers that an LLM chooses from, and series_observation artifacts turn stored series into text for the graph. The admin UI has a timeseries view with sparkline previews.
• Model and run tracking. gb_models records which model inferred each fact (0.4.0); gb_model_runs records every model call with tokens, cost and thinking level (0.19.0); gb_remember_runs logs each remember execution stage by stage (0.21.0). A remember manager now runs one pipeline at a time and returns a run ID at once, with a replaceable queue (0.23.0). Hooks for embedding programs are documented in docs/hooks.md.

Admin UI

• Introduced at the start of the week under /v1/gb/admin/: datasets with counts, d3 force-directed graph with fact validity, vector DB stats, delete button, and the eval DB side by side.
• Evals block with experiments, runs, history and trace flow graphs; web search card; model runs and remember runs views; left-hand view switcher (0.14.0); in-page modals instead of browser dialogs; version and commit link in the corner.

Training (Python sidecar + Modal)

• Sidecar (0.24.0). A FastAPI service in sidecar/, a Go client, Dockerfile.sidecar, docker-compose.yml (server + sidecar on one network). Go only talks to the sidecar, which proxies to a pluggable compute provider (Modal first).
• Gemma 4 fine-tuning and inference (0.26.0). 4B (Unsloth, A10G) and 12B (transformers + peft, A100); the image was later modernised (Unsloth, torch 2.10, CUDA 12.8).
• Training API under /v1/gb/training/ (0.30.0–0.31.0): JSONL dataset upload handled by Go and sent with each job. Training jobs are tracked in gb_training_job_runs and started from the admin UI with a dataset picker, live SSE progress and loss graph (0.27.0–0.28.0). Jobs can be stopped; failed jobs log a traceback.
• Modal management (0.33.0–0.34.0). The UI shows backends and Modal deployment status, and can deploy, cancel and stop apps and manage volumes.
• Trained models and inference (0.38.0–0.46.0). Trained models are tracked with their weights; inference runs on a chosen model in a warm container (idle timeout, Stop button, cold-start indicator); inference requests, tokens and timing are stored and shown with past replies (model runs became inferences in 0.42.0).
• Evals of trained models with an LLM judge (0.49.0–0.50.0). An Eval button asks the model the questions of its training dataset and has an external LLM score the answers (POST /v1/gb/training/models/{id}/evals); the admin UI streams answers and verdicts live over SSE. Knowledge evals and training evals are split into evals/knowledge/ and evals/training/.
• A 500-example world-knowledge dataset generator (economics, finance, geopolitics) and a design note on training data attribution.

Other

• Versioning starts (0.1.0): VERSION embedded in the binary, CHANGELOG.md, gligabao version, GET /version, and agent rules to bump the version on every change.
• run_pypi_upload.sh publishes the Python client to PyPI; the server default port is 7878.

Breaking changes

• No database migrations. Most schema changes this week required recreating the database (new columns and tables for sessions, chunks, models, model runs, artifacts and others). Delete the DB file and the eval DB and let the server recreate them.
• gb_llm_calls replaced by gb_model_runs (0.19.0), later renamed to inferences (0.42.0).
• go run ./evals is now go run ./evals/knowledge (0.49.0); ./run_evals.sh is unchanged.
• The Go API of api.Register, server.NewHandler and related functions gained extra arguments (Jev, web searcher, providers, manager).
• Sidecar routes were reorganised under /training, /infer, /evals and /datasets; the sidecar's dataset endpoints were then removed (datasets are managed by Go). The training API lives under /v1/gb/training/.

Other changes

• Refactors: the image, remember and recall pipelines moved into memory_image, memory_remember, memory_recall and memory_core; Fact view of an edge; snake_case file names; Modal code under providers/modal/; Gemma 4 code in ai_core/gemma4 with a model-family registry.
• Eval runner can run a single suite (-suite, -list-suites); new evals for timeseries ingestion and chunking.
• Fixes: Gemma 4 turn markers so models stop, zstd job-start decoding, Modal apps list hanging, Modal 303 redirects on long inference calls, silenced access log for status polling.
• docs/not-included.md lists things deliberately left out (e.g. a per-session turn cache).

Releases

Selected releases (there were more, including patch releases; see CHANGELOG.md):

Week 2026-W41 2026-10-05 – 2026-10-11

The project started on 2026-10-09, so this week covers 3 days (56 commits). No versions were released yet: version tracking and the changelog arrived in W42.

Summary

gligabao went from an empty repo to a working temporal knowledge-graph memory server. It has a CLI and HTTP API, remember and recall endpoints backed by an LLM, datasets owned by users, SQLite/PostgreSQL storage, vector search, an embeddable Go API, a first Python client, and an eval runner. The shape of the code (packages, module layout) was reorganised several times while this settled.

Highlights

• Core memory API. POST /v1/gb/remember extracts entities and facts from text with an LLM (Anthropic, claude-haiku-5-5 by the end of the week) and stores them as a graph. POST /v1/gb/recall answers questions from the graph and returns the evidence.
• Bi-temporal facts (Graphiti model). Episodes carry valid_at; facts are edges with valid_at, invalid_at and expired_at, so the graph keeps how long a fact was true. A separate events table was dropped in favour of this.
• Datasets and users. Memories, entities and edges are scoped to a dataset (default main) owned by a user_id, with soft delete and REST endpoints. GET /v1/gb/datasets/{name}/graph exports a dataset's graph as JSON.
• Storage backends. SQLite and PostgreSQL behind one internal/db layer (split into relational, graph and vector clients bundled in db.DB). Vector stores: a Pinecone backend, then sqlite-vec, replaced by pure-Go chromem-go (no more CGO).
• Ontologies. OWL ontologies can be loaded and updated.
• Embeddings and cost tracking. OpenAI text-embedding-3-small embeddings; every LLM call records tokens and cost.
• Embedding and CLI. A public Go API at the repo root (github.com/deepblue-phoenix/gligabao) so other programs can embed the server; a gligabao serve command (cobra); TOML config (bin/gligabao.toml) holding port, API keys, vector store and DB backend.
• Python client. Skeleton with remember().
• Observability. A monitoring package with system event hooks, structured logging with logrus, and ATIF trajectories (step-by-step traces of remember/recall) for eval calls.
• Evals. A Go eval runner with remember/recall cases (e.g. a job_change case), suites in files, a -v flag, eval endpoints that return ATIF trajectories, and run_evals.sh. Docs for evals and ATIF.
• Packaging. Dockerfile and run_build_container.sh; run_tests.sh; a README with project description and DB/remember/recall sections.

Other changes

• Timestamps standardised as RFC 3339 DATETIME with shared time helpers.
• Many package moves (server logic into internal/server, API handlers split per endpoint, prompts in their own files, internal/db/* subpackages, CLI to cmd/gligabao) and the Go module rename to github.com/deepblue-phoenix/gligabao.
• A dataset lifecycle test across the relational, graph and vector DBs; pretty-printed SQL in logs.