Telosieve

Telosieve is a read-only evaluation system for infrastructure instructions. Before a desired-state tool acts, Telosieve asks a deliberately uncomfortable question: what if the instruction itself is wrong?

It compares authenticated intent with corroborated observations and separately defined viability rules. It then tests the declared ways those sources could be faulty. If every surviving case supports the same bounded result, Telosieve records a certificate. If the evidence is missing, stale, inconsistent, or unsafe under any surviving case, it refuses instead of guessing.

Current boundary: Telosieve evaluates and records decisions but does not change Kubernetes, OpenTofu, Redis, PostgreSQL, or HTTP targets. It is an evaluation candidate, not a general safety proof, and still requires independent assessment.

The problem in one example

Suppose a Kubernetes controller receives a signed instruction to replace healthy state. A normal reconciler may treat that signature as enough authority and faithfully apply a poisoned instruction. Telosieve keeps the signed goal separate from what multiple read-only collectors observe and from the rules describing what must remain viable. It asks which sources could be wrong, removes each suspect source in turn, and accepts a result only when the independently checked survivors agree.

How Telosieve works

1. Keep evidence separate. Goal instructions, observed state, and viability rules retain their own provenance rather than being merged into one trusted input.
2. Verify before reasoning. Telosieve checks identity, signatures, lineage, freshness, schemas, exact-byte observation quorum, and resource bounds.
3. Test what could be wrong. It evaluates the configured fault hypotheses, excluding each suspect authority before deriving and independently checking a plan.
4. Agree or refuse. Every surviving hypothesis must support the same viable result. Ambiguity, disagreement, malformed evidence, timeouts, or unsupported input produce an explicit refusal.

Current status

Public source, hosted CI, package publication, and the website are authorized for the v0.2.0-rc.4 evaluation release. Production promotion, autonomous actuation, and stronger safety claims remain separately governed. See Release Strategy and Public Opening Decision.

Five-minute local path

Requirements: stable Rust 1.97 or newer and dependencies already present in the Cargo cache.

cargo test --locked --offline
mkdir -p out
cargo run --locked --offline -- run \
  scenarios/benign.json out/benign-certificate.json out/ledger.jsonl
cargo run --locked --offline -- run \
  scenarios/poisoned-goal.json out/refusal-certificate.json out/ledger.jsonl

The benign scenario emits a deterministic bounded certificate. The poisoned-goal scenario refuses. Neither command mutates an external target system.

After the public crate is available, install the evaluation CLI with cargo install telosieve --version 0.2.0-rc.4.

Run the versioned evaluation boundary with:

cargo run --locked --offline -- evaluate evaluation/config.example.json

Inspect the exact compiled capability contract with:

cargo run --locked --offline -- evaluation-capabilities

For rollback-detecting history, deletion-authorization consumption, reference actuation, backup, restore, and recovery commands, use the Evaluation CLI Guide, Actuator Recovery Guide, and Evaluation Lifecycle Guide.

Choose an evaluation path

Each qualification distinguishes real-system coverage from simulated control planes, loopback-only transport, shared administration, or absent organisational independence. Those limitations are evidence, not footnotes.

External assessment

Assessors should begin with the External Assessment Guide. It defines:

• how to authenticate the trust-record digest through a separate channel;
• how to verify the handoff before executing its binary;
• mandatory integrity tests and environment-dependent integration tests;
• adversarial and lifecycle expectations;
• the findings format and evidence-return procedure.

The Assessor Handoff is retained only for historical Post-M15 reproduction and is not the current candidate procedure.

Safety boundary and invariants

The core invariants are:

1. authority provenance is authenticated and never silently merged;
2. every supported evaluation mode requires an exact-byte observation quorum;
3. suspect evidence is excluded under the declared hypothesis;
4. a transition is allowed only when every surviving hypothesis agrees and viability independently accepts it;
5. unsupported, stale, divergent, oversized, replayed, or malformed evidence fails closed;
6. current integration modes write evidence only and have no target mutation authority.

The bounded generated state space contains no reproduced unsafe approval, but finite enumeration is not a proof for arbitrary systems or attackers. Read Architecture, Threat Model, Soundness Case, Observation Quorum, and Adversarial Coverage before making stronger claims.

Development and verification

The complete repository-owned gate is:

./scripts/ci-local.sh

It runs formatting, linting, Rust and Python tests, documentation and metadata checks, supply-chain validation, deterministic packaging, adversarial load, real disposable integration qualifications, reproducible builds, and diff hygiene. GitHub Actions runs the portable subset on pull requests and master; the complete local gate remains required for release decisions.

Useful focused commands:

cargo test --locked --offline --all-targets --all-features
cargo run --locked --offline --example state_space -- results/generated-state-space.json
python3 scripts/validate-brand.py
python3 scripts/validate-open-source-readiness.py

Contribution, security-reporting, and release rules are in Contributing, Security Policy, Code of Conduct, and Changelog.

Documentation map

Repository policy

Telosieve is licensed under Apache License 2.0. The repository uses master as its default branch. Every milestone is delivered through a feature branch, full local CI, remote pull-request diff review, and squash merge. Public distribution does not authorize telemetry, production deployment, mutation authority, or stronger claims.