cortexdb-cli 0.7.1__tar.gz → 0.8.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/PKG-INFO +213 -6
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/README.md +212 -5
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/__init__.py +1 -1
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/admin.py +1 -1
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/beliefs.py +65 -8
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/changes.py +212 -35
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/conflicts.py +6 -0
- cortexdb_cli-0.8.0/cortexdb_cli/commands/corrections.py +514 -0
- cortexdb_cli-0.8.0/cortexdb_cli/commands/derivation.py +1667 -0
- cortexdb_cli-0.8.0/cortexdb_cli/commands/derivation_jobs.py +377 -0
- cortexdb_cli-0.8.0/cortexdb_cli/commands/episodes.py +457 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/experience.py +96 -14
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/facts.py +39 -7
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/import_cmd.py +5 -1
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/publish.py +1 -1
- cortexdb_cli-0.8.0/cortexdb_cli/commands/review.py +238 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/rollups.py +1 -1
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/common.py +118 -3
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/errors.py +498 -5
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/harness_packs_data.py +6 -6
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/main.py +14 -1
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/output.py +107 -5
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/pyproject.toml +1 -1
- cortexdb_cli-0.7.1/cortexdb_cli/commands/episodes.py +0 -153
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/client.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/__init__.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/access.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/admin_access.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/answer.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/apps.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/audit.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/auth.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/claims.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/code.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/compose.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/config_cmd.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/directory.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/entities.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/erase.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/export_cmd.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/forget.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/init.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/interactive.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/onboard.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/policy.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/recall.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/scopes.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/search.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/tokens.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/understanding.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/watch.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/commands/wire.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/config.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/onboarding.py +0 -0
- {cortexdb_cli-0.7.1 → cortexdb_cli-0.8.0}/cortexdb_cli/state.py +0 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.5
|
|
2
2
|
Name: cortexdb-cli
|
|
3
|
-
Version: 0.
|
|
3
|
+
Version: 0.8.0
|
|
4
4
|
Summary: Command-line interface for CortexDB — the long-term memory layer for AI.
|
|
5
5
|
Project-URL: Homepage, https://cortexdb.ai
|
|
6
6
|
Project-URL: Documentation, https://cortexdb.ai/docs
|
|
@@ -36,9 +36,11 @@ Command-line interface for [CortexDB](https://cortexdb.ai) — the long-term mem
|
|
|
36
36
|
|
|
37
37
|
Wraps the v1 HTTP API in a small, fast Click + Rich CLI. Anonymous signup
|
|
38
38
|
in one command, no email or card; works against the public SaaS or any
|
|
39
|
-
self-hosted CortexDB deployment. Version 0.
|
|
40
|
-
|
|
41
|
-
|
|
39
|
+
self-hosted CortexDB deployment. Version 0.8.0 covers CortexDB 0.15.0,
|
|
40
|
+
governed memory formation included: derivation policies, corrections, review
|
|
41
|
+
and re-derivation; and CortexDB 0.14.x, shared memory included: the access
|
|
42
|
+
API, change sets, the directory, applications, rollups, publishing and the
|
|
43
|
+
new erasures.
|
|
42
44
|
|
|
43
45
|
## Install
|
|
44
46
|
|
|
@@ -81,6 +83,35 @@ When a token expires you have two safe options:
|
|
|
81
83
|
For a second brain alongside the first, isolate instead of replacing:
|
|
82
84
|
`cortexdb --config-dir <dir> init`, or set `CORTEXDB_HOME`.
|
|
83
85
|
|
|
86
|
+
## What's new for CortexDB 0.15.0 (cortexdb-cli 0.8.0)
|
|
87
|
+
|
|
88
|
+
CortexDB 0.15.0 adds governed memory formation: control over what its
|
|
89
|
+
background enrichment learns, and corrections that stay corrected. Each
|
|
90
|
+
command below needs a server that serves its capability: a server before
|
|
91
|
+
0.15.0 answers it 404, which reads like a missing record, and the hint says
|
|
92
|
+
the server predates the command.
|
|
93
|
+
|
|
94
|
+
- **`cortexdb derivation`**: `status` and `decisions` (what was learned from
|
|
95
|
+
an event, and why not), `policy`, `templates`, `taxonomy`, `test` (a draft
|
|
96
|
+
tried on real events, writing nothing), `stage` (stage, preview and
|
|
97
|
+
activate a policy), `settings`, `texts`, `feed` and `consumers`, and the
|
|
98
|
+
re-derivation jobs: `rederive` (a dry run unless `--apply`, of the unsynced
|
|
99
|
+
rows unless `--events`), `job`, `cancel` and `report`.
|
|
100
|
+
- **`cortexdb corrections`** (`add`, `list`, `show`, `undo`) and **`cortexdb
|
|
101
|
+
memory about`** (`--corrections`): fix a wrong memory so it stays fixed,
|
|
102
|
+
rather than forget it.
|
|
103
|
+
- **`cortexdb review`** (`list`, `approve`, `reject`): decide what a
|
|
104
|
+
derivation policy held back.
|
|
105
|
+
- **`cortexdb episodes declare`** and **`episodes delete`**: a worker's own
|
|
106
|
+
episodes.
|
|
107
|
+
- **New options**: `--derived-by NAME@VERSION` on `experience write`, `beliefs
|
|
108
|
+
create` and `episodes declare`; `--include derivation` on `facts list`,
|
|
109
|
+
`facts timeline`, `beliefs list` and `beliefs why`; `--session ID` on
|
|
110
|
+
`recall`, `search`, `answer` and `compose`.
|
|
111
|
+
- **Warnings**: a write that names a directive nothing reads prints
|
|
112
|
+
"accepted, not enforced: NAME", and a change set that keeps a scope's
|
|
113
|
+
`enrich` says so.
|
|
114
|
+
|
|
84
115
|
## What's new for CortexDB 0.14.1 (cortexdb-cli 0.7.1)
|
|
85
116
|
|
|
86
117
|
- **Change sets that take long.** A staging, a preview or an activation whose
|
|
@@ -164,10 +195,14 @@ cortexdb search "..." granular event-level search
|
|
|
164
195
|
cortexdb answer "..." recall + LLM answer
|
|
165
196
|
cortexdb compose "..." a markdown document from memory
|
|
166
197
|
cortexdb forget --memory-id | --idempotency-key | --capture-key ...
|
|
167
|
-
cortexdb episodes {list,get,delete}
|
|
198
|
+
cortexdb episodes {list,get,declare,delete}
|
|
168
199
|
cortexdb entities {list,get,link}
|
|
169
200
|
cortexdb facts {list,timeline}
|
|
170
201
|
cortexdb beliefs {list,why,build,create}
|
|
202
|
+
cortexdb derivation {status,decisions,policy,templates,taxonomy,stage,test,settings,feed,consumers,texts}
|
|
203
|
+
cortexdb corrections {add,list,show,undo}
|
|
204
|
+
cortexdb memory {about}
|
|
205
|
+
cortexdb review {list,approve,reject}
|
|
171
206
|
cortexdb conflicts {list,show,resolve}
|
|
172
207
|
cortexdb claims {history}
|
|
173
208
|
cortexdb concepts {list,coverage,synthesize}
|
|
@@ -206,7 +241,10 @@ takes a tenant root uses the first segment of it.
|
|
|
206
241
|
(your application's admitted mounts), `--consistency`, `--at-least TOKEN` and
|
|
207
242
|
`--purpose ID` (the purpose the read is for: a grant whose `when` names a
|
|
208
243
|
purpose holds only for that one; `access check`, `access explain` and
|
|
209
|
-
`access authzen evaluate` decide a chain for one too)
|
|
244
|
+
`access authzen evaluate` decide a chain for one too) and `--session ID` (the
|
|
245
|
+
conversation session the read is made in, CortexDB 0.15.0: where a read-time
|
|
246
|
+
use rule is in force, memory from other sessions, or older than its window, is
|
|
247
|
+
withheld, and `warnings` says how many events). A write returns a consistency token with `--consistency`; a read that passes it
|
|
210
248
|
to `--at-least` sees that write:
|
|
211
249
|
|
|
212
250
|
```bash
|
|
@@ -217,6 +255,175 @@ cortexdb recall "ship" --at-least "$TOKEN"
|
|
|
217
255
|
`experience write` also takes `--provenance EVENT_ID` (erasing the source
|
|
218
256
|
erases the write), `--intent` and `--idempotency-key`.
|
|
219
257
|
|
|
258
|
+
### derivation: what CortexDB learned, and how (CortexDB 0.15.0)
|
|
259
|
+
|
|
260
|
+
```bash
|
|
261
|
+
cortexdb derivation status org:acme/user:alice # layers and extraction caught up?
|
|
262
|
+
cortexdb derivation decisions org:acme/user:alice evt_0196... # what became of one event
|
|
263
|
+
cortexdb facts list --include derivation # how each fact was made
|
|
264
|
+
cortexdb facts timeline --subject Alice --predicate lives_in --include derivation
|
|
265
|
+
cortexdb beliefs list --include derivation
|
|
266
|
+
cortexdb beliefs why belief_01... --include derivation
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
On a server that serves `derivation_provenance_v1`, `derivation status`
|
|
270
|
+
adds the extraction line to the layer builds: how many of the scope's
|
|
271
|
+
events the background enrichment has not derived yet, learned from, derived
|
|
272
|
+
with nothing admitted, held for review or failed on, with its own caught-up.
|
|
273
|
+
`derivation decisions` says what became of one event: learned, nothing
|
|
274
|
+
admitted, held, pending, skipped (and why: enrichment off, a reference
|
|
275
|
+
root, a `directives.extract` naming no model stage, a typed triple, no
|
|
276
|
+
text) or failed (retrying or not), with the models, the prompt version and
|
|
277
|
+
the policy; a rejected candidate is counted by its rule id, never shown.
|
|
278
|
+
`--include derivation` adds each fact's or belief's derivation (verdict,
|
|
279
|
+
models, prompt version, gate, policy; `no stamp` for a row made before
|
|
280
|
+
0.15.0) as a column. An older server has no extraction line, answers
|
|
281
|
+
`derivation decisions` with a 404 (the hint says so) and ignores
|
|
282
|
+
`--include`.
|
|
283
|
+
|
|
284
|
+
### derivation policies, settings, texts and the feed (CortexDB 0.15.0)
|
|
285
|
+
|
|
286
|
+
```bash
|
|
287
|
+
cortexdb derivation policy org:acme/app:companion/user:bob # what derives here, under which rules
|
|
288
|
+
cortexdb derivation templates # consumer, minimal, enterprise, ...
|
|
289
|
+
cortexdb derivation templates consumer > policy.json # one template's body, to edit
|
|
290
|
+
cortexdb derivation test org:acme/app:companion --file policy.json --recent 20 # try it first, writes nothing
|
|
291
|
+
cortexdb derivation stage org:acme/app:companion --file policy.json # stage, preview, activate
|
|
292
|
+
cortexdb derivation stage org:acme/app:companion --template consumer
|
|
293
|
+
cortexdb derivation settings org:acme/app:companion/user:bob --deny-predicate diet
|
|
294
|
+
cortexdb derivation settings org:acme/app:companion/user:bob --consent "health:health coaching"
|
|
295
|
+
cortexdb derivation texts org:acme --all # the policy texts, without their content
|
|
296
|
+
cortexdb derivation feed org:acme/app:tutor --consumer acme-level --cursor-file level.cursor --follow
|
|
297
|
+
cortexdb experience write --triple Alice level advanced --derived-by acme-level@1.1.0
|
|
298
|
+
```
|
|
299
|
+
|
|
300
|
+
A derivation policy is a registry record of kind `derive` at
|
|
301
|
+
`<scope>/attrs:derive`: `derivation stage` stages it at the scope's root,
|
|
302
|
+
prints the preview's derivation section (the record's hash before and after,
|
|
303
|
+
the effective policy's before and after with the rules that move, the texts it
|
|
304
|
+
names) and activates it with the preview's hash after asking (`--yes` skips
|
|
305
|
+
the question). `derivation test` tries a draft first (the same `--file`, or
|
|
306
|
+
`--changeset ID` for one you staged): extraction and the gate over the newest
|
|
307
|
+
events (`--recent N`, 50 by default) or named ones (`--events FILE`), each
|
|
308
|
+
candidate's verdict and rule beside the policy in force, the diff and the
|
|
309
|
+
cost. It writes nothing, but its model calls are real: `--max-cost` (1 US
|
|
310
|
+
dollar by default) caps them, and a larger estimate is refused before any
|
|
311
|
+
call. `changes stage --file` also takes a `{"scope": SCOPE, "derive":
|
|
312
|
+
{...}}` entry. `derivation policy` says whether anything derives at a scope and
|
|
313
|
+
why not (the server's ceiling, which no policy widens), the mode, each
|
|
314
|
+
restriction and where it was set, and the steering in force. `derivation
|
|
315
|
+
settings` changes one scope's own restrictions and consents with no change set:
|
|
316
|
+
it reads the record, changes what its flags name and writes the whole record
|
|
317
|
+
back. `derivation feed` prints a scope's events and the erasures that touch
|
|
318
|
+
them, one JSON object a line, for a worker outside CortexDB; `--cursor-file`
|
|
319
|
+
resumes where the last run's printed items end. A write-back is a typed triple
|
|
320
|
+
stamped `--derived-by NAME@VERSION` (`beliefs create` takes the stamp too).
|
|
321
|
+
`stage`, `settings` and `texts` need a shard armed for apply format 11; the
|
|
322
|
+
hint of a 503 `FORMAT_UPGRADE_PENDING` says what holds it. A server before
|
|
323
|
+
CortexDB 0.15.0 answers `policy`, `templates`, `taxonomy`, `test`,
|
|
324
|
+
`settings`, `texts` and `feed` with a 404, which reads like a missing record:
|
|
325
|
+
the hint says the server predates the command's capability, and
|
|
326
|
+
`GET /v1/admin/version` lists the capabilities a server serves.
|
|
327
|
+
|
|
328
|
+
### corrections and memory about (CortexDB 0.15.0)
|
|
329
|
+
|
|
330
|
+
```bash
|
|
331
|
+
cortexdb memory about org:acme/app:companion/user:bob # what is known, with sources and fact ids
|
|
332
|
+
cortexdb corrections add org:acme/app:companion/user:bob --reject fact_0196... --reason "I never lived in Boston"
|
|
333
|
+
cortexdb corrections add org:acme/app:companion/user:bob --replace fact_0196... --value Denver --valid-from 2026-03-01
|
|
334
|
+
cortexdb corrections add org:acme/app:companion/user:bob --pin fact_0196...
|
|
335
|
+
cortexdb corrections list org:acme/app:companion/user:bob
|
|
336
|
+
cortexdb corrections undo org:acme/app:companion/user:bob cor_0196...
|
|
337
|
+
```
|
|
338
|
+
|
|
339
|
+
To fix a wrong memory, correct it rather than forget it: a forget of what was
|
|
340
|
+
derived can be learned again from the events, a correction is not. A
|
|
341
|
+
correction names the fact's claim, and changes every live fact of it in the
|
|
342
|
+
scope and below: a reject deletes them and keeps the claim from being learned
|
|
343
|
+
again (`--bind subject_predicate` or `subject` widen it to every value, or
|
|
344
|
+
everything about the subject, for good), a replace writes the new value as
|
|
345
|
+
your own fact and closes the old ones, a pin keeps any extracted value from
|
|
346
|
+
superseding it, a confirm raises its authority. A reject and an undo ask first
|
|
347
|
+
on a terminal, saying what they delete or bring back (`--yes` from a script).
|
|
348
|
+
The same `corrections add` sent again replays its first attempt: its default
|
|
349
|
+
idempotency key is a hash of the request. `memory about` lists every fact and
|
|
350
|
+
belief about the scope's subject with the memories it came from, which is also
|
|
351
|
+
the subject's export; `--corrections` adds the scope's corrections. A server
|
|
352
|
+
before CortexDB 0.15.0 answers `corrections` and `memory about` with a 404,
|
|
353
|
+
which reads like a missing fact or correction: the hint says the server
|
|
354
|
+
predates `corrections_v1`.
|
|
355
|
+
|
|
356
|
+
### review: what a derivation policy held back (CortexDB 0.15.0)
|
|
357
|
+
|
|
358
|
+
```bash
|
|
359
|
+
cortexdb review list org:acme/clinic:north # oldest first: what each states, why it was held
|
|
360
|
+
cortexdb review list org:acme/clinic:north --topic health --descend --all --json
|
|
361
|
+
cortexdb review approve org:acme/clinic:north hld_0196... --reason "confirmed with patient"
|
|
362
|
+
cortexdb review reject org:acme/clinic:north hld_0196... --bind subject_predicate --yes
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
A derivation policy's review rules (a topic or predicate held for review, the
|
|
366
|
+
`review` mode, a refused writer, a low confidence) hold a candidate memory
|
|
367
|
+
CortexDB extracted before it is stored: a held candidate is in no store,
|
|
368
|
+
recall or answer until a reviewer decides it. `review list` prints the open
|
|
369
|
+
candidates held at a scope, oldest first: what each states, its topic, the
|
|
370
|
+
rule that held it, when it was held and when it lapses, and the text around
|
|
371
|
+
its quote while its memory is there to quote. `--topic`, `--rule` and `--descend`
|
|
372
|
+
(the scopes under it you may read, with `scope.read.descend`) filter it;
|
|
373
|
+
`--limit`, `--cursor` and `--all` page it. `review approve` makes each held
|
|
374
|
+
candidate a fact of its memory and prints the fact's id. `review reject`
|
|
375
|
+
erases each and keeps its claim suppressed by a correction of origin `review`
|
|
376
|
+
(`cortexdb corrections list SCOPE --origin review`, which `corrections undo`
|
|
377
|
+
reverses): this claim, from its memory and every memory captured before the
|
|
378
|
+
decision (`--bind claim`, the default), or every value of its subject and
|
|
379
|
+
predicate, past and future (`--bind subject_predicate`). A reject asks first on
|
|
380
|
+
a terminal (`--yes` from a script). Each decision is its own: one that is
|
|
381
|
+
refused (decided before, its memory erased meanwhile) leaves the others made,
|
|
382
|
+
and the command exits 1 after printing every result; more than 100 go in
|
|
383
|
+
requests of 100. A candidate nobody decides lapses after the policy's
|
|
384
|
+
`review.lapse_days` (30 by default). A Writer of the scope, or a reviewer the
|
|
385
|
+
policy names, decides; the routes need a shard armed for apply format 11. A
|
|
386
|
+
server before CortexDB 0.15.0 answers `review` with a 404, which reads like a
|
|
387
|
+
missing scope or candidate: the hint says the server predates
|
|
388
|
+
`derivation_review_v1`.
|
|
389
|
+
|
|
390
|
+
### outside workers: declared episodes and the feed's consumers (CortexDB 0.15.0)
|
|
391
|
+
|
|
392
|
+
```bash
|
|
393
|
+
cortexdb episodes declare org:acme/team:support --file outage-call.json --derived-by acme-sessionizer@2.1.0
|
|
394
|
+
cortexdb episodes list --scope org:acme/team:support # the declared ones are marked
|
|
395
|
+
cortexdb episodes delete org:acme/team:support ep_0196... # a declared episode
|
|
396
|
+
cortexdb episodes delete evt_0196... --reason "posted by mistake" # one event: the forget it always was
|
|
397
|
+
cortexdb derivation consumers org:acme/app:tutor # who reads the feed here
|
|
398
|
+
```
|
|
399
|
+
|
|
400
|
+
A worker outside CortexDB that groups events into an episode (a call, a
|
|
401
|
+
session, a case) declares it: `outage-call.json` holds `events` (1 to 1,024
|
|
402
|
+
`evt_` ids) and, as it needs them, `name`, `summary`, `started_at`,
|
|
403
|
+
`ended_at`, `actors_involved`, `derived_by` and `idempotency_key`; the CLI
|
|
404
|
+
checks its shape as the server does before sending. The episode is served
|
|
405
|
+
beside the built ones with `declared: true` and is erased with any event it
|
|
406
|
+
names. The same declaration sent again answers its first episode: the default
|
|
407
|
+
idempotency key is a hash of the request. Only a declared episode can be
|
|
408
|
+
deleted (a built one answers 404). `derivation consumers` lists the workers
|
|
409
|
+
whose reads of `derivation feed` reach a scope, which an erasure's receipt
|
|
410
|
+
names: their principal, what they read, the last event delivered, when they
|
|
411
|
+
last read, whether they are idle and when their mark is purged. Declaring and
|
|
412
|
+
deleting need a shard armed for apply format 11; below it `derivation
|
|
413
|
+
consumers` says no consumer is recorded. A server before CortexDB 0.15.0 has
|
|
414
|
+
none of these routes: `episodes declare` answers 405 there (the server lists
|
|
415
|
+
episodes at that path), and `episodes delete` of a declared episode and
|
|
416
|
+
`derivation consumers` answer 404; the hint says the server predates the
|
|
417
|
+
capability.
|
|
418
|
+
|
|
419
|
+
Writes say which of their directives nothing reads: `consolidate_into`,
|
|
420
|
+
`confidence_floor`, `ttl_for_belief_layer`, `embed` and `async` are
|
|
421
|
+
accepted and validated, but nothing reads them, and `experience`, each item
|
|
422
|
+
of `experience bulk` and `import --server` print "accepted, not enforced:
|
|
423
|
+
NAME" for each one they named. `changes stage`, `parts` and `preview` print "kept enrich: on at
|
|
424
|
+
PATH" for a companion put that keeps the stored `enrich` (a put that does
|
|
425
|
+
not name `enrich` keeps it; only `"enrich": "inherit"` clears it).
|
|
426
|
+
|
|
220
427
|
### access
|
|
221
428
|
|
|
222
429
|
```bash
|
|
@@ -4,9 +4,11 @@ Command-line interface for [CortexDB](https://cortexdb.ai) — the long-term mem
|
|
|
4
4
|
|
|
5
5
|
Wraps the v1 HTTP API in a small, fast Click + Rich CLI. Anonymous signup
|
|
6
6
|
in one command, no email or card; works against the public SaaS or any
|
|
7
|
-
self-hosted CortexDB deployment. Version 0.
|
|
8
|
-
|
|
9
|
-
|
|
7
|
+
self-hosted CortexDB deployment. Version 0.8.0 covers CortexDB 0.15.0,
|
|
8
|
+
governed memory formation included: derivation policies, corrections, review
|
|
9
|
+
and re-derivation; and CortexDB 0.14.x, shared memory included: the access
|
|
10
|
+
API, change sets, the directory, applications, rollups, publishing and the
|
|
11
|
+
new erasures.
|
|
10
12
|
|
|
11
13
|
## Install
|
|
12
14
|
|
|
@@ -49,6 +51,35 @@ When a token expires you have two safe options:
|
|
|
49
51
|
For a second brain alongside the first, isolate instead of replacing:
|
|
50
52
|
`cortexdb --config-dir <dir> init`, or set `CORTEXDB_HOME`.
|
|
51
53
|
|
|
54
|
+
## What's new for CortexDB 0.15.0 (cortexdb-cli 0.8.0)
|
|
55
|
+
|
|
56
|
+
CortexDB 0.15.0 adds governed memory formation: control over what its
|
|
57
|
+
background enrichment learns, and corrections that stay corrected. Each
|
|
58
|
+
command below needs a server that serves its capability: a server before
|
|
59
|
+
0.15.0 answers it 404, which reads like a missing record, and the hint says
|
|
60
|
+
the server predates the command.
|
|
61
|
+
|
|
62
|
+
- **`cortexdb derivation`**: `status` and `decisions` (what was learned from
|
|
63
|
+
an event, and why not), `policy`, `templates`, `taxonomy`, `test` (a draft
|
|
64
|
+
tried on real events, writing nothing), `stage` (stage, preview and
|
|
65
|
+
activate a policy), `settings`, `texts`, `feed` and `consumers`, and the
|
|
66
|
+
re-derivation jobs: `rederive` (a dry run unless `--apply`, of the unsynced
|
|
67
|
+
rows unless `--events`), `job`, `cancel` and `report`.
|
|
68
|
+
- **`cortexdb corrections`** (`add`, `list`, `show`, `undo`) and **`cortexdb
|
|
69
|
+
memory about`** (`--corrections`): fix a wrong memory so it stays fixed,
|
|
70
|
+
rather than forget it.
|
|
71
|
+
- **`cortexdb review`** (`list`, `approve`, `reject`): decide what a
|
|
72
|
+
derivation policy held back.
|
|
73
|
+
- **`cortexdb episodes declare`** and **`episodes delete`**: a worker's own
|
|
74
|
+
episodes.
|
|
75
|
+
- **New options**: `--derived-by NAME@VERSION` on `experience write`, `beliefs
|
|
76
|
+
create` and `episodes declare`; `--include derivation` on `facts list`,
|
|
77
|
+
`facts timeline`, `beliefs list` and `beliefs why`; `--session ID` on
|
|
78
|
+
`recall`, `search`, `answer` and `compose`.
|
|
79
|
+
- **Warnings**: a write that names a directive nothing reads prints
|
|
80
|
+
"accepted, not enforced: NAME", and a change set that keeps a scope's
|
|
81
|
+
`enrich` says so.
|
|
82
|
+
|
|
52
83
|
## What's new for CortexDB 0.14.1 (cortexdb-cli 0.7.1)
|
|
53
84
|
|
|
54
85
|
- **Change sets that take long.** A staging, a preview or an activation whose
|
|
@@ -132,10 +163,14 @@ cortexdb search "..." granular event-level search
|
|
|
132
163
|
cortexdb answer "..." recall + LLM answer
|
|
133
164
|
cortexdb compose "..." a markdown document from memory
|
|
134
165
|
cortexdb forget --memory-id | --idempotency-key | --capture-key ...
|
|
135
|
-
cortexdb episodes {list,get,delete}
|
|
166
|
+
cortexdb episodes {list,get,declare,delete}
|
|
136
167
|
cortexdb entities {list,get,link}
|
|
137
168
|
cortexdb facts {list,timeline}
|
|
138
169
|
cortexdb beliefs {list,why,build,create}
|
|
170
|
+
cortexdb derivation {status,decisions,policy,templates,taxonomy,stage,test,settings,feed,consumers,texts}
|
|
171
|
+
cortexdb corrections {add,list,show,undo}
|
|
172
|
+
cortexdb memory {about}
|
|
173
|
+
cortexdb review {list,approve,reject}
|
|
139
174
|
cortexdb conflicts {list,show,resolve}
|
|
140
175
|
cortexdb claims {history}
|
|
141
176
|
cortexdb concepts {list,coverage,synthesize}
|
|
@@ -174,7 +209,10 @@ takes a tenant root uses the first segment of it.
|
|
|
174
209
|
(your application's admitted mounts), `--consistency`, `--at-least TOKEN` and
|
|
175
210
|
`--purpose ID` (the purpose the read is for: a grant whose `when` names a
|
|
176
211
|
purpose holds only for that one; `access check`, `access explain` and
|
|
177
|
-
`access authzen evaluate` decide a chain for one too)
|
|
212
|
+
`access authzen evaluate` decide a chain for one too) and `--session ID` (the
|
|
213
|
+
conversation session the read is made in, CortexDB 0.15.0: where a read-time
|
|
214
|
+
use rule is in force, memory from other sessions, or older than its window, is
|
|
215
|
+
withheld, and `warnings` says how many events). A write returns a consistency token with `--consistency`; a read that passes it
|
|
178
216
|
to `--at-least` sees that write:
|
|
179
217
|
|
|
180
218
|
```bash
|
|
@@ -185,6 +223,175 @@ cortexdb recall "ship" --at-least "$TOKEN"
|
|
|
185
223
|
`experience write` also takes `--provenance EVENT_ID` (erasing the source
|
|
186
224
|
erases the write), `--intent` and `--idempotency-key`.
|
|
187
225
|
|
|
226
|
+
### derivation: what CortexDB learned, and how (CortexDB 0.15.0)
|
|
227
|
+
|
|
228
|
+
```bash
|
|
229
|
+
cortexdb derivation status org:acme/user:alice # layers and extraction caught up?
|
|
230
|
+
cortexdb derivation decisions org:acme/user:alice evt_0196... # what became of one event
|
|
231
|
+
cortexdb facts list --include derivation # how each fact was made
|
|
232
|
+
cortexdb facts timeline --subject Alice --predicate lives_in --include derivation
|
|
233
|
+
cortexdb beliefs list --include derivation
|
|
234
|
+
cortexdb beliefs why belief_01... --include derivation
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
On a server that serves `derivation_provenance_v1`, `derivation status`
|
|
238
|
+
adds the extraction line to the layer builds: how many of the scope's
|
|
239
|
+
events the background enrichment has not derived yet, learned from, derived
|
|
240
|
+
with nothing admitted, held for review or failed on, with its own caught-up.
|
|
241
|
+
`derivation decisions` says what became of one event: learned, nothing
|
|
242
|
+
admitted, held, pending, skipped (and why: enrichment off, a reference
|
|
243
|
+
root, a `directives.extract` naming no model stage, a typed triple, no
|
|
244
|
+
text) or failed (retrying or not), with the models, the prompt version and
|
|
245
|
+
the policy; a rejected candidate is counted by its rule id, never shown.
|
|
246
|
+
`--include derivation` adds each fact's or belief's derivation (verdict,
|
|
247
|
+
models, prompt version, gate, policy; `no stamp` for a row made before
|
|
248
|
+
0.15.0) as a column. An older server has no extraction line, answers
|
|
249
|
+
`derivation decisions` with a 404 (the hint says so) and ignores
|
|
250
|
+
`--include`.
|
|
251
|
+
|
|
252
|
+
### derivation policies, settings, texts and the feed (CortexDB 0.15.0)
|
|
253
|
+
|
|
254
|
+
```bash
|
|
255
|
+
cortexdb derivation policy org:acme/app:companion/user:bob # what derives here, under which rules
|
|
256
|
+
cortexdb derivation templates # consumer, minimal, enterprise, ...
|
|
257
|
+
cortexdb derivation templates consumer > policy.json # one template's body, to edit
|
|
258
|
+
cortexdb derivation test org:acme/app:companion --file policy.json --recent 20 # try it first, writes nothing
|
|
259
|
+
cortexdb derivation stage org:acme/app:companion --file policy.json # stage, preview, activate
|
|
260
|
+
cortexdb derivation stage org:acme/app:companion --template consumer
|
|
261
|
+
cortexdb derivation settings org:acme/app:companion/user:bob --deny-predicate diet
|
|
262
|
+
cortexdb derivation settings org:acme/app:companion/user:bob --consent "health:health coaching"
|
|
263
|
+
cortexdb derivation texts org:acme --all # the policy texts, without their content
|
|
264
|
+
cortexdb derivation feed org:acme/app:tutor --consumer acme-level --cursor-file level.cursor --follow
|
|
265
|
+
cortexdb experience write --triple Alice level advanced --derived-by acme-level@1.1.0
|
|
266
|
+
```
|
|
267
|
+
|
|
268
|
+
A derivation policy is a registry record of kind `derive` at
|
|
269
|
+
`<scope>/attrs:derive`: `derivation stage` stages it at the scope's root,
|
|
270
|
+
prints the preview's derivation section (the record's hash before and after,
|
|
271
|
+
the effective policy's before and after with the rules that move, the texts it
|
|
272
|
+
names) and activates it with the preview's hash after asking (`--yes` skips
|
|
273
|
+
the question). `derivation test` tries a draft first (the same `--file`, or
|
|
274
|
+
`--changeset ID` for one you staged): extraction and the gate over the newest
|
|
275
|
+
events (`--recent N`, 50 by default) or named ones (`--events FILE`), each
|
|
276
|
+
candidate's verdict and rule beside the policy in force, the diff and the
|
|
277
|
+
cost. It writes nothing, but its model calls are real: `--max-cost` (1 US
|
|
278
|
+
dollar by default) caps them, and a larger estimate is refused before any
|
|
279
|
+
call. `changes stage --file` also takes a `{"scope": SCOPE, "derive":
|
|
280
|
+
{...}}` entry. `derivation policy` says whether anything derives at a scope and
|
|
281
|
+
why not (the server's ceiling, which no policy widens), the mode, each
|
|
282
|
+
restriction and where it was set, and the steering in force. `derivation
|
|
283
|
+
settings` changes one scope's own restrictions and consents with no change set:
|
|
284
|
+
it reads the record, changes what its flags name and writes the whole record
|
|
285
|
+
back. `derivation feed` prints a scope's events and the erasures that touch
|
|
286
|
+
them, one JSON object a line, for a worker outside CortexDB; `--cursor-file`
|
|
287
|
+
resumes where the last run's printed items end. A write-back is a typed triple
|
|
288
|
+
stamped `--derived-by NAME@VERSION` (`beliefs create` takes the stamp too).
|
|
289
|
+
`stage`, `settings` and `texts` need a shard armed for apply format 11; the
|
|
290
|
+
hint of a 503 `FORMAT_UPGRADE_PENDING` says what holds it. A server before
|
|
291
|
+
CortexDB 0.15.0 answers `policy`, `templates`, `taxonomy`, `test`,
|
|
292
|
+
`settings`, `texts` and `feed` with a 404, which reads like a missing record:
|
|
293
|
+
the hint says the server predates the command's capability, and
|
|
294
|
+
`GET /v1/admin/version` lists the capabilities a server serves.
|
|
295
|
+
|
|
296
|
+
### corrections and memory about (CortexDB 0.15.0)
|
|
297
|
+
|
|
298
|
+
```bash
|
|
299
|
+
cortexdb memory about org:acme/app:companion/user:bob # what is known, with sources and fact ids
|
|
300
|
+
cortexdb corrections add org:acme/app:companion/user:bob --reject fact_0196... --reason "I never lived in Boston"
|
|
301
|
+
cortexdb corrections add org:acme/app:companion/user:bob --replace fact_0196... --value Denver --valid-from 2026-03-01
|
|
302
|
+
cortexdb corrections add org:acme/app:companion/user:bob --pin fact_0196...
|
|
303
|
+
cortexdb corrections list org:acme/app:companion/user:bob
|
|
304
|
+
cortexdb corrections undo org:acme/app:companion/user:bob cor_0196...
|
|
305
|
+
```
|
|
306
|
+
|
|
307
|
+
To fix a wrong memory, correct it rather than forget it: a forget of what was
|
|
308
|
+
derived can be learned again from the events, a correction is not. A
|
|
309
|
+
correction names the fact's claim, and changes every live fact of it in the
|
|
310
|
+
scope and below: a reject deletes them and keeps the claim from being learned
|
|
311
|
+
again (`--bind subject_predicate` or `subject` widen it to every value, or
|
|
312
|
+
everything about the subject, for good), a replace writes the new value as
|
|
313
|
+
your own fact and closes the old ones, a pin keeps any extracted value from
|
|
314
|
+
superseding it, a confirm raises its authority. A reject and an undo ask first
|
|
315
|
+
on a terminal, saying what they delete or bring back (`--yes` from a script).
|
|
316
|
+
The same `corrections add` sent again replays its first attempt: its default
|
|
317
|
+
idempotency key is a hash of the request. `memory about` lists every fact and
|
|
318
|
+
belief about the scope's subject with the memories it came from, which is also
|
|
319
|
+
the subject's export; `--corrections` adds the scope's corrections. A server
|
|
320
|
+
before CortexDB 0.15.0 answers `corrections` and `memory about` with a 404,
|
|
321
|
+
which reads like a missing fact or correction: the hint says the server
|
|
322
|
+
predates `corrections_v1`.
|
|
323
|
+
|
|
324
|
+
### review: what a derivation policy held back (CortexDB 0.15.0)
|
|
325
|
+
|
|
326
|
+
```bash
|
|
327
|
+
cortexdb review list org:acme/clinic:north # oldest first: what each states, why it was held
|
|
328
|
+
cortexdb review list org:acme/clinic:north --topic health --descend --all --json
|
|
329
|
+
cortexdb review approve org:acme/clinic:north hld_0196... --reason "confirmed with patient"
|
|
330
|
+
cortexdb review reject org:acme/clinic:north hld_0196... --bind subject_predicate --yes
|
|
331
|
+
```
|
|
332
|
+
|
|
333
|
+
A derivation policy's review rules (a topic or predicate held for review, the
|
|
334
|
+
`review` mode, a refused writer, a low confidence) hold a candidate memory
|
|
335
|
+
CortexDB extracted before it is stored: a held candidate is in no store,
|
|
336
|
+
recall or answer until a reviewer decides it. `review list` prints the open
|
|
337
|
+
candidates held at a scope, oldest first: what each states, its topic, the
|
|
338
|
+
rule that held it, when it was held and when it lapses, and the text around
|
|
339
|
+
its quote while its memory is there to quote. `--topic`, `--rule` and `--descend`
|
|
340
|
+
(the scopes under it you may read, with `scope.read.descend`) filter it;
|
|
341
|
+
`--limit`, `--cursor` and `--all` page it. `review approve` makes each held
|
|
342
|
+
candidate a fact of its memory and prints the fact's id. `review reject`
|
|
343
|
+
erases each and keeps its claim suppressed by a correction of origin `review`
|
|
344
|
+
(`cortexdb corrections list SCOPE --origin review`, which `corrections undo`
|
|
345
|
+
reverses): this claim, from its memory and every memory captured before the
|
|
346
|
+
decision (`--bind claim`, the default), or every value of its subject and
|
|
347
|
+
predicate, past and future (`--bind subject_predicate`). A reject asks first on
|
|
348
|
+
a terminal (`--yes` from a script). Each decision is its own: one that is
|
|
349
|
+
refused (decided before, its memory erased meanwhile) leaves the others made,
|
|
350
|
+
and the command exits 1 after printing every result; more than 100 go in
|
|
351
|
+
requests of 100. A candidate nobody decides lapses after the policy's
|
|
352
|
+
`review.lapse_days` (30 by default). A Writer of the scope, or a reviewer the
|
|
353
|
+
policy names, decides; the routes need a shard armed for apply format 11. A
|
|
354
|
+
server before CortexDB 0.15.0 answers `review` with a 404, which reads like a
|
|
355
|
+
missing scope or candidate: the hint says the server predates
|
|
356
|
+
`derivation_review_v1`.
|
|
357
|
+
|
|
358
|
+
### outside workers: declared episodes and the feed's consumers (CortexDB 0.15.0)
|
|
359
|
+
|
|
360
|
+
```bash
|
|
361
|
+
cortexdb episodes declare org:acme/team:support --file outage-call.json --derived-by acme-sessionizer@2.1.0
|
|
362
|
+
cortexdb episodes list --scope org:acme/team:support # the declared ones are marked
|
|
363
|
+
cortexdb episodes delete org:acme/team:support ep_0196... # a declared episode
|
|
364
|
+
cortexdb episodes delete evt_0196... --reason "posted by mistake" # one event: the forget it always was
|
|
365
|
+
cortexdb derivation consumers org:acme/app:tutor # who reads the feed here
|
|
366
|
+
```
|
|
367
|
+
|
|
368
|
+
A worker outside CortexDB that groups events into an episode (a call, a
|
|
369
|
+
session, a case) declares it: `outage-call.json` holds `events` (1 to 1,024
|
|
370
|
+
`evt_` ids) and, as it needs them, `name`, `summary`, `started_at`,
|
|
371
|
+
`ended_at`, `actors_involved`, `derived_by` and `idempotency_key`; the CLI
|
|
372
|
+
checks its shape as the server does before sending. The episode is served
|
|
373
|
+
beside the built ones with `declared: true` and is erased with any event it
|
|
374
|
+
names. The same declaration sent again answers its first episode: the default
|
|
375
|
+
idempotency key is a hash of the request. Only a declared episode can be
|
|
376
|
+
deleted (a built one answers 404). `derivation consumers` lists the workers
|
|
377
|
+
whose reads of `derivation feed` reach a scope, which an erasure's receipt
|
|
378
|
+
names: their principal, what they read, the last event delivered, when they
|
|
379
|
+
last read, whether they are idle and when their mark is purged. Declaring and
|
|
380
|
+
deleting need a shard armed for apply format 11; below it `derivation
|
|
381
|
+
consumers` says no consumer is recorded. A server before CortexDB 0.15.0 has
|
|
382
|
+
none of these routes: `episodes declare` answers 405 there (the server lists
|
|
383
|
+
episodes at that path), and `episodes delete` of a declared episode and
|
|
384
|
+
`derivation consumers` answer 404; the hint says the server predates the
|
|
385
|
+
capability.
|
|
386
|
+
|
|
387
|
+
Writes say which of their directives nothing reads: `consolidate_into`,
|
|
388
|
+
`confidence_floor`, `ttl_for_belief_layer`, `embed` and `async` are
|
|
389
|
+
accepted and validated, but nothing reads them, and `experience`, each item
|
|
390
|
+
of `experience bulk` and `import --server` print "accepted, not enforced:
|
|
391
|
+
NAME" for each one they named. `changes stage`, `parts` and `preview` print "kept enrich: on at
|
|
392
|
+
PATH" for a companion put that keeps the stored `enrich` (a put that does
|
|
393
|
+
not name `enrich` keeps it; only `"enrich": "inherit"` clears it).
|
|
394
|
+
|
|
188
395
|
### access
|
|
189
396
|
|
|
190
397
|
```bash
|
|
@@ -95,7 +95,7 @@ def admin_layers(ctx: click.Context) -> None:
|
|
|
95
95
|
|
|
96
96
|
# -- retention (unified WAL) -------------------------------------------------
|
|
97
97
|
#
|
|
98
|
-
# The operator surface over the
|
|
98
|
+
# The operator surface over the retention plane. Every write here is
|
|
99
99
|
# irreversible in effect - an applied sweep removes expired captured events,
|
|
100
100
|
# everything about them under an `erase` rule, their raw data under a
|
|
101
101
|
# `keep_learned` one - so reporting is the default on both mutating commands
|