Telosieve

Read-only evaluation candidate

Question the instruction
before enforcing it.

Telosieve examines infrastructure intent as evidence, not truth. It keeps authorities separate, tests what could be wrong, and refuses when the surviving evidence cannot justify one bounded result.

See how it works Assessment guide

Current boundary: evaluates and records decisions; never mutates Kubernetes, OpenTofu, Redis, PostgreSQL, or HTTP targets.

The control-plane assumption

A valid signature does not make an instruction true.

Reconcilers are designed to make reality match desired state. If that desired state is stale, compromised, inconsistent, or malicious, perfect reconciliation can faithfully create the wrong outcome. Telosieve investigates a stricter model: authenticate every source, trust none implicitly, and preserve uncertainty as a result.

01

Provenance is not truth

Identity and signatures show where evidence came from. They do not prove that its content is correct.

02

Refusal is useful

When surviving explanations disagree, stopping with inspectable evidence is safer than inventing certainty.

03

Bounds are part of correctness

Inputs, hypotheses, execution time, outputs, and compatibility are explicitly limited and fail closed.

How it works

One instruction. Several possible realities.

Telosieve accepts a result only after it survives the declared faults and an independent viability check.

Swipe or use the arrow keys to explore the full architecture

Goal instructions, corroborated observations, and viability rules remain separate. Telosieve verifies provenance, tests declared fault hypotheses, independently checks every surviving plan, and emits either a bounded certificate or an explicit refusal while retaining evidence.
Current integration modes are read-only. A certificate records a bounded evaluation result; it does not authorize production actuation.

Testable integrations

Meet infrastructure where its evidence lives.

Each integration uses narrow read-only permissions, explicit resource bounds, and mandatory observation quorum.

K8S

Kubernetes

Shadow snapshots and live four-read coherence checks against a real disposable API server.

 TOFU

OpenTofu

Saved plan bytes through corroborating producers, with no backend credentials or apply path.

 RDS

Redis

Bounded namespace collection through technically restricted read-only identities.

 PG

PostgreSQL

Repeatable-read snapshots through SELECT-only roles, including concurrent-writer tests.

 HTTP

HTTP/JSON

Fixed GET-only collection with bearer or TLS 1.3 mutual authentication and revocation checks.

 V1

Your system

A versioned executable adapter and quorum response contract for further read-only integrations.

Evidence, not theatre

Negative findings stay visible.

Telosieve retains refusals, exclusions, timeouts, unsupported cases, and known correlated-fault limits alongside successful results. Project-controlled testing is labelled as such. Independent operation and independent assessment are not implied.

Explore adversarial coverage
4
supported evaluation modes
10
registered adversarial classes
0
target mutations in supported integrations
1
required outcome: agreement or refusal

What Telosieve does not claim

  • A general proof of safety
  • Production-ready actuation
  • Independent organisational fault domains
  • Protection against arbitrary attackers
  • Legal name or mark clearance
  • Completed independent assessment

Inspect the mechanism

Confidence should have to explain itself.

Build the candidate locally, replay the retained scenarios, challenge the trust boundary, or implement a read-only integration.

Explore the repository Install from crates.io