kortecxdocs

Quickstart

Prove exactly-once delivery in 60 seconds — run, crash mid-commit, replay, and get the same digest back.

The fastest way to understand Kortecx is to break it on purpose. In four commands you run a workflow, crash the process mid-commit, replay from the journal, and watch the digest come back identical — because committed work is re-read, not re-run.

The 60-second exactly-once proof

kx run    --journal /tmp/kx.db --content /tmp/kx-content        # → a6b5c679… (8/8 committed)
rm -f /tmp/kx.db; rm -rf /tmp/kx-content
kx run    --journal /tmp/kx.db --content /tmp/kx-content --crash-at post-commit-vtc
kx replay --journal /tmp/kx.db --content /tmp/kx-content        # → SAME digest (re-read, not re-run)

What happened:

  1. kx run executes the workflow, appending each step to the journal and committing content. It prints a digest — a6b5c679… — and reports 8/8 committed.
  2. You wipe the journal and content store to start clean.
  3. kx run --crash-at post-commit-vtc injects a crash right after a commit, mid-flight — exactly the kind of failure that breaks naive pipelines.
  4. kx replay re-derives state from the append-only journal. Committed motes are re-read from the content store, not recomputed — so the digest is the same.

Why this matters

The digest is a content-addressed fingerprint of the run. Same digest after a crash means the system recovered to the exact same state — exactly-once delivery with transparent recovery, not "probably once" with manual cleanup.

Next

  • Core concepts — what a mote, journal, projection, and commit protocol actually are.
  • kx CLI reference — every flag on run and replay.
  • Recipes — compose multi-step workflows.