ZTL Judge

io.github.inventor1975Published by GitHub account inventor1975v1.1.0Updated Nov 5, 2026

Zero-trust logic judge: ZFL claims, algebra derivation steps, sets defined by a property.

VerifiedStreamable HTTPWeb executableDeveloper ToolsAI & ML

Overview

AI-generated overview

Remote zero-trust logic judge that evaluates ZFL claims, algebra derivation steps and self-referential sets, returning verdicts with warranty grades.

What you can do
  • Look up the ZFL table language and ready-made example documents
  • Judge a ZFL document and get a two-valued verdict with disposition, grade and warranty
  • Check an algebra derivation step by step to see whether each step keeps the same solutions
  • Judge sets defined by a property, including self-referential ones, and get quarantine passports
  • Fetch ready-made requests for the derivation and set checkers
When to use it
Useful when you want a claim, a chain of algebraic steps, or a self-referential definition (Russell-style sets, policy rules, webs of trust) checked by a deterministic judge rather than by an LLM's own reasoning, with unverified inputs explicitly marked.
Requirements
A remote streamable HTTP endpoint; no package, account, API key or header is declared. The assistant must be able to reach the hosted service.
Before you install
The server judges the formal document you send, so the verdict is only as good as the translation into ZFL; unverified rows are marked Z rather than resolved. Documents and claims are sent to a third-party hosted service. Verdicts are advisory and should not be treated as proof of real-world facts.

Installation

In SourceWeft

  1. Open ZTL Judge in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.inventor1975%2Fztl-judge/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "ztl-judge": {
      "type": "http",
      "url": "https://api.ztljudge.com/mcp"
    }
  }
}

README

ZTLStudio

The AI translates; the measured core judges — truth is never granted on credit, not even to the translator.

A local studio for judging claims and paradoxes. You state one in natural language (any language); an LLM only translates it into ZFL, the formal table language — it never judges. A deterministic, measured ZTL core does the judging: verdicts with warranties, quarantine passports for self-referential systems, and a deterministic back-reading that verbalizes exactly what the core read from your table.

The pipeline embodies the logic it serves: the LLM's output is an unverified input (the mark Z), and the core is the customs house — truth is never granted on credit, not even to the translator.

human ──meta-chat──► the AI fills a ZFL table (rows + a claim), you sign off                         │                         ▼ validator ──► the deterministic core judges                         ▼ back-reading (no AI — the second auditor)                         ▼                   verdict · warranty · passport · stipulations

Run

python3 ztlstudio.py        # → http://localhost:8190

Python stdlib only; the ZTL core is vendored in ztlcore/, so a clone is self-contained (no submodules, no dependencies). The AI is optional: with no key the studio runs in pro mode — fill the ZFL table by hand. To enable AI translation, open ⚙ Model, pick a provider + model + key, or set the env var, or drop a key into a local .<provider>_key file (all gitignored — no keys ship).

What you hand it: one table, no genre to declare

ZFL v2 is a single table of rows plus a claim. Each row states a fact, its status (T verified / F refuted / Z unverified — the zero-trust default), its ground, and — importantly — what it means in words (the polarity auditor: it lets the back-reading catch an encoding that says the opposite of what you intended). You never declare whether this is a "statement" or a "paradox": the genre is computed, and whichever instruments apply fire — a verdict + warranty for a claim, a passport for a self-referential system.

The studio ships 41 worked examples — open one to see the exact shape of the table, then edit it. The back-reading verbalizes what the core actually read, so your translation is audited by a component that cannot hallucinate.

The workflow

  1. Meta-chat — describe the claim in your language; the AI fills the table's rows and asks only when formalization is genuinely blocked. It knows its boundary: arithmetic, quantities and numeric wordplay get an honest "does not formalize into propositional ZTL", never an invented encoding.
  2. The table — a grid of rows, the grounds bar, and the claim line, all hand-editable (pros skip the chat entirely). Run validates and judges; validator issues are machine-readable and can be fed back to the AI to repair.
  3. The report — the core's verdict, its warranty grade (hereditary / sound / until-verification), the passport of unverified inputs, and the completion table — followed by the deterministic back-reading and an optional AI explanation that retells the verdict and is forbidden to re-judge (labeled unverified by definition: the pipeline applies its own logic to itself).

What the core reports

  • Claims — the verdict (T/F — verdicts are always two-valued; Z is a mark on an input, never a verdict), the warranty grade, the passport of unverified inputs, and the completion table showing how the verdict behaves under every reading of the unverified rows.
  • Self-referential systems — the grounded part (identical in every fixed point), the quarantine set, and a passport per component: PARADOX (no classical solution — permanent refusal, with the oscillation period), UNDERDETERMINED (refusal until stipulation), INPUT (until verification), DOWNSTREAM (inherited).

Providers

Keys stay on this machine, read in order: the Settings field, the env var (GROQ_API_KEY, ANTHROPIC_API_KEY, …), then a local .<provider>_key file. Supported: Groq, Anthropic (Claude), OpenAI, OpenRouter, DeepSeek, Gemini, xAI, NVIDIA. A stronger model formalizes cleaner; the core judges the same regardless of who translated.

Related

  • ZTL — the logic itself: the kernel, the papers, and the ZFL language.
  • introspect — the same zero-trust core applied to code: a taint analyzer for seven languages.

AI disclosure

Built by Claude (Anthropic) as architect and implementer, with Vitaly Reznik as human curator and decision-maker, under a strict honesty discipline: mark boundaries honestly, measure — don't guess, and never claim more than was verified.

License

Dual-licensed under MIT and Apache-2.0 (see LICENSE-MIT, LICENSE-APACHE).

Source: README.md at commit c7e6f19

Tools

6

language

The ZFL language: the columns of a row, the document fields, their meaning and rules.

Takes no parameters.

examples

Worked examples: questions already written as ZFL documents, ready to judge.

Takes no parameters.

judge

Judge a ZFL document with ZTL, a zero-trust logic: three values, two-valued connectives. Args: document: The ZFL document, as an object or as JSON text: {"rows": [{"name": ..., "means": ..., "status": ..., "ground": ...}], "claim": ...}. Returns: The verdict with its disposition and grade, the receipt, the instruments that applied, the issues found, and what the core read. Read the verdict WITH its disposition: T EARNED = established; F REFUTED = false; F OPEN or Z OPEN = NOT ESTABLISHED, it could still turn either way (do not report it as false) — `why` and `unverified` say what to check; ON CREDIT = holds only on an unverified ground. A compound claim gets T or F; a claim that is a single name gets that name's own value, Z while unverified. The full report is returned whatever `ask` says.

Parametersdocumentrequired

check_steps

Check an algebra derivation step by step: does each step keep exactly the same solutions? Args: request: {"equations": ["x^2 = x", "x = 1"], "var": "x", "domain": [lo, hi] or null, "domain_verified": true}. Each equation is the next step; one unknown; + - * / ^ with whole powers. Returns: The chain's verdict (its weakest step) and each step's: EARNED = same solutions on the domain; ON CREDIT = the same, on an unverified domain; REFUTED = a solution is lost (e.g. cancelling a factor that can be 0) or gained (e.g. clearing a denominator where the original was undefined), with the witness and the cause; E = the step divides by an expression that is 0 for every value. A request above the public limits is refused with the reason (ok: false, refused).

Parametersrequestrequired

judge_naive

Judge sets defined by a property, self-reference allowed (Russell's set, a web of trust, a policy rule). Args: universe: {"sets": {name: {"list": [...]} | {"data": {name: "T"|"F"|"Z"}} | {"abs": formula}}, "claims": [formula, ...]}. Formulas: ["in", a, S], ["not", f], ["and"|"or"|"imp"|"iff", f, g], ["all"|"ex", "y", f], ["eq", S, T]; an abs set's own variable is "x". Every name is also an object. Returns: Per set: the members and non-members the definitions ground, and a passport for each membership they leave undecided — PARADOX (no stipulation can repair it), UNDERDETERMINED (consistent; a decision is owed), INTRINSIC, INPUT (verify the given cell), DOWNSTREAM (inherits a quarantine). Per claim: EARNED / REFUTED / EARNED IF STABLE / REFUTED IF STABLE / OPEN, the cells it rests on with their passports, and for a universal claim the instances left undecided. Oversized requests are refused with the reason.

Parametersuniverserequired

checker_examples

Ready requests for check_steps and judge_naive (the kernels' own examples).

Takes no parameters.

Version history

3
  1. v1.1.0LatestNov 5, 2026
  2. v1.0.1Oct 29, 2026
  3. v1.0.0Sep 29, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts