belief-check
A machine's way to know when it's wrong.
Two services agree on a contract. Months later one of them changes what a
field means — amount_cents starts carrying 49.99 instead of 4999 —
and every type checker, schema validator, and integration test stays green.
The field kept its name. The wrongness flows.
belief-check is the smallest thing that catches that: a document stating what you believe about a counterparty, a way to check whether it still holds, and a tripwire that stops the call when it doesn't.
Zero dependencies. Python 3.9+, standard library only. No registry, no coordination, no permission, no cryptographic identity.
python example.py
That runs the whole proof against a live local server — drift, containment, recovery — in four acts.
The three layers
Layer 1 — the belief. A plain JSON document: the schema fingerprint you built against, a semantic version, and probes that test meaning (values, units, types), not just shape.
Layer 2 — the check. POST /.well-known/belief-check. The counterparty
answers confirmed or diff. On silence — non-200, timeout, endpoint absent
— the consumer runs its probes itself and decides unilaterally. The first
adopter gets fail-fast against counterparties that never cooperate.
Layer 3 — the tripwire. Detection is the primitive; blocking is policy,
and the two are never fused. FAIL_CLOSED (default) blocks the call with a
typed, machine-readable BeliefBroken. HALF_OPEN blocks but re-checks and
resumes automatically. OBSERVE never blocks and hands every break to your
own handler.
Consumer
from beliefcheck import Belief, Probe, Tripwire, Policy, schema_hash
belief = Belief(
counterparty="https://api.example.com",
schema_hash=schema_hash(openapi_dict), # the artifact you built against
semantic_version="orders-v2",
probes=[
Probe(
name="amount-is-integer-cents",
request={"method": "POST", "path": "/orders/echo",
"body": {"sku": "A1", "qty": 1}},
expect={"status": 200, "body_subset": {"amount_cents": 4999}},
)
],
)
wire = Tripwire(belief, policy=Policy.FAIL_CLOSED, interval=300)
wire.connect() # check on connect
order = wire.guard(client.place_order, "A1") # blocks if belief broke
guard also probes on anomaly: if the wrapped call raises, the wire checks
whether drift — rather than ordinary failure — is the real cause, and tells
you which.
Producer
One route makes you a cooperating counterparty:
from beliefcheck import answer, WELL_KNOWN, schema_hash
@app.post(WELL_KNOWN)
def belief_check(doc: dict):
return answer(doc, schema_hash(CURRENT_SCHEMA), "orders-v2")
A handshake confirmed is your claim about your declared state, not
verified behavior. The producer never executes a stranger's probes against
itself — that is a security hole, not a courtesy. Probes verify behavior;
handshakes verify declaration.
Read this before trusting it
Probes are examples, not invariants. The two outcomes are not symmetric:
A fired check is proof of drift. A passing check is evidence of health, never proof.
Drift outside your probes' coverage is invisible to this protocol. Widen
coverage; accept that it never closes. Probes are also perishable — the most
dangerous deployment is a confidently FAIL_CLOSED wire whose probes went
stale. Treat a long-silent tripwire with suspicion, not comfort.
Anything claiming a silent tripwire means a healthy integration is lying to you.
When not to use this
- You own both sides and deploy them together. Types, review, and shared libraries already enforce the contract; a belief document is a second source of truth that can rot.
- The producer is simple and stable. If probe maintenance costs more than the expected breakage, the ROI is negative.
- The drift you fear is syntactic. Strict parsers and compiled protos already scream at shape changes. This protocol exists for the residue: meaning changes that survive the type system.
- You need audit or compliance guarantees. This is a safety mechanism, not an evidence trail. Proving to a third party that you checked is attestation, a different layer.
It earns its keep where drift is silent, dangerous, and outside your control.
Non-goals
Signatures, gossip, history, anchoring, repair, and dashboards are other layers answering other questions. SPEC.md is one page and is complete as written.
License
Apache-2.0. No CLA.
Metadata
Release files for belief-check 0.3.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| belief_check-0.3.4.tar.gz | 16.0 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| belief_check-0.3.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 29.9 kB
Release files / belief_check-0.3.4.tar.gz
| Download URL | belief_check-0.3.4.tar.gz |
|---|---|
| Size | 16.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a7a7248383d24eceb27666d747ea04a3a0f096a1df7d58e465d6ef906c188218
|
|
BLAKE2b-256 checksum How to use checksums |
1a1daed87ee938c659372507f2a0e99a9c58ea98286975910586341dcff3fa2e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 28, 2026.
Transparency logRelease files / belief_check-0.3.4-py3-none-any.whl
| Download URL | belief_check-0.3.4-py3-none-any.whl |
|---|---|
| Size | 13.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
d8d60de74ff7d87c7653144335fa09f541fa6fc477acdf6d96f847bb705d9ca0
|
|
BLAKE2b-256 checksum How to use checksums |
5383a61dd53d522f5e1a4da562433e0f901b255cd1b2849c1ed61104bd9861b3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 28, 2026.
Transparency logSecurity for belief-check 0.3.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for belief_check-0.3.4.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 28, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.