KALYX
Execution Evidence Integrity Platform

KALYX

Execution Evidence Integrity Platform

Know when execution history can no longer be trusted.

KALYX captures execution events into an append-only hash-chained ledger, verifies historical integrity deterministically, records trusted checkpoint boundaries, and compares them against an external Raspberry Pi anchor.

Learn how it works View architecture Trust model Future roadmap GitHub ↗
KALYX evidence flow Execution events enter a chained ledger, pass through deterministic verification and checkpointing, then compare with an independent Raspberry Pi anchor. The verification signal changes from verified to tampered after a mismatch. EVIDENCE CONTINUITY / LIVE MODEL EXEC EVENT process / argv EXEC EVENT user / action HASH-CHAINED LEDGER #001 prev: 0000… hash: a7c3… #002 prev: a7c3… hash: 19ef… #003 hash mismatch VERIFICATION canonical replay VERIFIED → TAMPERED LOCAL CHECKPOINT verified boundary checkpoint_hash: c42e… EXTERNAL BOUNDARY Raspberry Pi anchor chain MATCH checkpoint boundaries only COMPARE HOST BOUNDARY WITH INDEPENDENT ANCHOR
01 / The problem

Logs are easy to collect.
Harder to trust.

Traditional logs can look valid even after old entries are modified, reordered, truncated, or replaced. KALYX focuses on evidence continuity.

  • Was this record appended after the previous one?
  • Did a record change after it was written?
  • Was a verified boundary removed or replaced?
  • Is the current ledger trusted enough for detection?
  • Does an independent anchor still agree with the host?
Traditional log viewer
ResultLOOKS NORMAL
KALYX verification
ResultHASH MISMATCH / TRUST LOST
02 / Product capabilities

What KALYX does.

One evidence pipeline, exposed through thin interfaces and bounded by explicit trust decisions.

01

Execution ingestion

Accepts sample logs, raw execsnoop-style lines, structured API events, and live eBPF execsnoop output.

02

Processing pipeline

Validates, enriches, and normalizes accepted events through shared backend services.

03

Hash-chained ledger

Appends canonical JSONL records with sequence, previous hash, and record hash.

04

Deterministic verification

Recomputes the chain and reports the first boundary that can no longer be trusted.

05

Local checkpoints

Records previously verified ledger boundaries in a chained checkpoint history.

06

Trust-state enforcement

Blocks new ingestion when current ledger or checkpoint continuity is untrusted.

07

Rule-based detection

Runs deterministic, explainable rules after successful full-ledger hash-chain verification.

08

Alert persistence

Writes replay-safe alerts to JSONL using stable signatures to avoid duplicates.

09

FastAPI host backend

Exposes status, ingestion, verification, detection, alerts, ledger, and anchoring operations.

10

Angular operations console

Provides a local browser interface over the host FastAPI backend.

11

Raspberry Pi anchor

Stores checkpoint boundaries in a physically separable Pi-side hash chain.

12

Anchor comparison

Compares the latest local checkpoint with the latest reachable external anchor.

03 / Architecture

Thin interfaces. Shared integrity core.

CLI, FastAPI, and Angular expose the system. Integrity decisions live in shared host services. Raspberry Pi anchoring adds an external comparison boundary.

System architectureHover or focus a node to inspect its responsibility.
KALYX system architecture CLI, FastAPI, and Angular sit above a shared Host Evidence Core. Angular communicates only with FastAPI. The host anchor client communicates with the Raspberry Pi anchor API, which stores a separate anchor chain. INTERFACES / ACCESS LAYERS HOST EVIDENCE CORE EXTERNAL ANCHOR HTTP only latest anchor CLIkalyx FastAPI Host APIkalyx-api Angular Dashboardlocal operations console Pipelinevalidate / enrich / normalize Verification Enginedeterministic full-chain replay Trust Gateenforce before append Checkpoint Chainlocal verified boundaries Hash-Chained Ledgerappend-only JSONL Anchor Clientsubmit / compare Detection Engineverification-gated rules Alert Logdeduplicated JSONL Pi Anchor APIPOST /anchor Pi Anchor Chaincheckpoint boundaries only
Architecture boundary. Interfaces expose the product; shared host services make integrity decisions; the Raspberry Pi holds an independent checkpoint comparison boundary.
Access layers only.
CLI, API, and Angular do not implement separate integrity engines.
Host-controlled path.
Angular calls Host FastAPI; host-to-Pi traffic uses KALYX_ANCHOR_URL.
Boundary, not omniscience.
The Pi stores checkpoints rather than validating every execution event.
04 / End-to-end workflow

From event capture to independent comparison.

The trust gate happens before append. Detection branches from successful full-ledger hash-chain verification; it does not require checkpoint continuity.

01

Capture event

Receive sample, raw, structured, or live execsnoop input.

02

Validate

Reject missing fields, invalid PIDs, and blank commands.

03

Enrich

Add best-effort process and execution context.

04

Normalize

Produce a stable event shape for hashing and rules.

05

Trust gate

Refuse append when ledger or checkpoint state is untrusted.

06

Append

Write a canonical record linked to the previous hash.

07

Verify ledger

Replay the full hash chain and locate any failure boundary.

08

Checkpoint

Record a safe local boundary after successful verification.

09

Anchor to Pi

Submit the latest checkpoint boundary to the Pi service.

10

Compare

Report whether local and external checkpoint states agree.

11

Run detection

Evaluate rules after full-ledger hash-chain verification.

12

Persist alerts

Write only alerts whose stable signatures are new.

05 / Trust model

Evidence continuity, not event truth.

KALYX can prove specific properties about records it accepted and the continuity of their stored history. Its guarantees stop before source authenticity and full-host trust.

What KALYX can verify

  • A ledger record changed after append
  • A previous-hash link was broken
  • Ledger JSON is malformed
  • The first untrusted record boundary
  • A local checkpoint was edited
  • Checkpoint history was reordered or broken
  • The ledger fell behind a previous checkpoint
  • Detection ran after full-ledger hash-chain verification
  • A checkpoint was compared with an external anchor

What KALYX cannot verify

  • Event source authenticity
  • Kernel-level trust
  • Resistance to full host compromise
  • Malware prevention or process blocking
  • Complete remote attestation
  • Continuous anchor availability
  • Truthfulness of process identity or metadata
  • Independent Pi validation of every host event
“KALYX verifies records it accepted. KALYX does not prove the original event source was truthful.”This is the core product boundary—not a footnote.
06 / Operational trust states

Trust is explicit.

VERIFIED

The ledger verifies and does not conflict with the latest local checkpoint.

PARTIALLY_TRUSTED

Verification failed after one or more earlier records remained trusted.

UNTRUSTED

Ledger or checkpoint continuity cannot be trusted operationally.

EMPTY

The ledger file exists but contains no execution records.

NO_LEDGER

No ledger file exists yet for the current environment.

Important boundary: ingestion is blocked when current ledger or checkpoint state is untrusted. Detection is skipped when full-ledger hash-chain verification fails, but detection currently does not evaluate local checkpoint continuity. Full hash-chain verification itself does not require checkpoint trust.

07 / Raspberry Pi anchoring

Independent comparison boundary.

The host holds the ledger. A Raspberry Pi can hold checkpoint boundaries somewhere physically separate, giving local history an external state to compare against.

Why a Raspberry Pi?

It is low-cost, suited to always-on operation, and can run a small API outside the host without introducing distributed-system complexity.

  • Can be physically separated from the monitored host
  • Small, source-distributed FastAPI anchor service
  • Independent storage for checkpoint comparison
  • Demonstrates trust separation without claiming perfect authority
Anchor workflow
Host ledgerverified locally
Checkpointboundary payload
Pi anchor chainstored externally

The Pi stores checkpoint metadata—not each execution event:

checkpoint_indexrecord_countlast_seqlast_hashcheckpoint_hashprevious_checkpoint_hashpi_anchor_hash

Submission states

ACCEPTEDALREADY_ANCHOREDREJECTED_STALEREJECTED_INVALID

Comparison states

MATCHBEHINDAHEADDIVERGENCENO_ANCHORUNREACHABLE
08 / Angular operations console

A local console over Host FastAPI.

The dashboard presents backend state and operations. It does not decide trust in the browser, and it never calls the Raspberry Pi directly.

Interface preview — abstract, not live data

Overview

Trust state, ledger state, checkpoint state, recent records, and alerts.

VERIFIED
Ledger entries
—
Checkpoint state
VALID_CHECKPOINT_CHAIN
Last hash
••••••••
Recent records
Recent alerts
09 / API surface

Two APIs. Two responsibilities.

Host FastAPI exposes product operations. The Pi API accepts and returns checkpoint boundaries.

Host API · kalyx-api :8000
GET/
GET/status
POST/verify
POST/ingest
POST/detect
GET/alerts
GET/ledger
GET/anchor/status
POST/anchor
Anchor API · kalyx-anchor :8081
POST/anchor
GET/anchor/latest?ledger_id=…

Protection boundary

When configured, an API key protects host operational routes. It is lightweight local protection—not full authentication, sessions, RBAC, or event-source attestation. The current Pi API is unauthenticated.

10 / Detection engine

Deterministic by design.

No ML. No threat-intelligence dependency. Rules remain inspectable, testable, and explainable.

Full hash-chain verification gateDeterministic orderingStable alert signaturesReplay-safe persistence
DELETE_CREATE

Delete followed by create on the same target within a configured window.

MODIFY_BURST

Repeated modifications against the same known target over a short interval.

DESTRUCTIVE_BURST

Multiple destructive actions by the same user or session in a short window.

SCRIPTED_DESTRUCTIVE_ACTION

Delete or modify activity launched by scripting parents outside interactive sessions.

Detection verifies the full ledger hash chain before replaying records. It does not currently consult local checkpoint continuity, so it must not be described as enforcing checkpoint trust.

11 / Testing and validation

Trust behavior is tested, not implied.

The repository focuses automated coverage on integrity, corruption, trust gates, anchoring, APIs, and typed Angular service/state behavior.

Ledger integrity
Corruption handling
Concurrent appends
Pipeline validation
Ingestion trust gate
Local checkpoints
Trust states
Detection rules
Alert persistence
Host API
Anchor service
Angular service/state

GitHub Actions

Pull requests and pushes to main validate:

✓ Python source compilation
✓ Backend pytest suite
✓ Angular production build

Angular browser/Karma tests exist locally but are not currently run by CI.

12 / Limitations

Credibility starts with the boundary.

KALYX is intentionally narrow. It makes accepted evidence tamper-evident; it does not turn a local prototype into a complete security platform.

Does not prevent attacks or block processes
Does not prove source truthfulness
Does not guarantee kernel trust
Cannot resist full host compromise alone
Does not replace SIEM or EDR
Does not provide signed anchor receipts yet
Does not validate every event on the Pi
Does not provide production deployment hardening yet
Local JSONL is inspectable, not indexed storage
Full verification is O(n)
Detection uses rules, not ML
The current Pi API is unauthenticated
13 / Design tradeoffs

Simple enough to inspect.

The current architecture favors visible mechanics and deterministic behavior over operational scale.

JSONL ledger

Append-friendly, inspectable, and straightforward to verify one line at a time.

Canonical hashing

Stable serialization keeps deterministic verification reproducible.

Local checkpoints

Record verified boundaries before an external anchor is available.

Raspberry Pi anchor

Adds an independent comparison boundary without a large distributed system.

Rule-based detection

Produces explainable outputs with explicit, testable semantics.

Thin interfaces

CLI, API, and Angular reuse shared host services rather than duplicating trust logic.

No database yet

Keeps the early product inspectable until indexed storage is operationally necessary.

Technical reference

Technical Documentation

KALYX Learn provides the product overview. The documents below contain the detailed technical implementation.

03

Threat Model

Security assumptions, trust boundaries, guarantees and limitations.

Read Threat Model →
05

Configuration

Environment variables, runtime options and deployment configuration.

View Configuration →
14 / Future enhancements

The next trust boundaries.

These are planned directions, not current capabilities or production guarantees.

Future / Cryptographic hardening

Authenticate the exchange

  • Signed anchor receipts
  • HMAC or signature support
  • Host identity

Why: reduce forged or unauthenticated submissions and strengthen provenance and auditability—without implying legal admissibility by itself.

Future / Verification scale

Move beyond full replay

  • Incremental verification
  • Checkpoint continuation
  • Merkle-style segmentation

Why: the current full-chain replay is simple and deterministic but grows more expensive with the ledger.

Future / Anchor hardening

Strengthen the boundary

  • Authenticated Pi API
  • Signed Pi responses
  • Multiple anchors
  • Cloud or appliance option

Why: improve confidence in external comparison and reduce dependence on one unauthenticated anchor.

Future / Event provenance

Raise source confidence

  • Authenticated ingestion
  • Source identity
  • Stronger collection pipeline

Why: hash chains preserve accepted evidence; provenance work would improve confidence in where that evidence originated.

Future / Storage and operations

Make evaluation repeatable

  • Indexed storage
  • Exportable evidence bundles
  • Docker packaging
  • Reproducible demos

Why: make KALYX easier to run, inspect, and evaluate beyond a source checkout.

Future / Research track

Evaluate the model

  • Tampering scenarios
  • Evidence provenance model
  • Remote attestation comparison
  • Open-source research

Why: test the trust model against documented scenarios and turn design claims into evidence-backed findings.

15 / Product status

Working product. Early stage.

KALYX is source-distributed and runs from a checkout. It is not yet packaged as a production service.

Working today

  • Host FastAPI API
  • CLI
  • Angular operations console
  • Local ledger and checkpoint services
  • Raspberry Pi anchor service

Active product work

  • Security hardening
  • Deployment automation
  • Scalable storage
  • Signed anchoring
  • Stronger event provenance
16 / One narrow question
“KALYX is not trying to solve every security problem. It focuses on one narrow but critical question: can collected execution evidence still be trusted?”
View GitHub ↗ Read Architecture Explore API Threat Model