source  →  verdict  →  proof  →  audit  →  governed effect

  no policy  ·  no authority  ·  no silent downgrade
  DENY is the default  ·  governance IS the runtime

  ~ ~ ~  Code that has to justify itself before it acts.  ~ ~ ~

What Is Thirsty-Lang?

The programming language wars are not over. Governance is just getting started.

Thirsty-Lang is not a prettier Python syntax. It is a defensive runtime and language stack where execution, side effects, policy, proof, authority, audit, mutation, symbolic constraints, and build outputs are all treated as governable surfaces — not as afterthoughts bolted on after deployment.

Every other language asks: can this code run? Thirsty-Lang asks a harder question: should this code run, under the current authority, policy, and context — and can it produce cryptographic proof that it did so correctly?

Instead of treating governance as documentation, middleware, or operational policy applied after deployment, Thirsty-Lang treats governance as part of the execution model itself. Sensitive operations require policy evaluation, authority verification, proof generation, and audit recording before producing governed effects.

The result is a language designed to make execution not only programmable, but explainable, attributable, and defensible — by construction, not by convention.

The core posture is non-negotiable:

Install

pip install thirsty-lang

Pinned release:

pip install thirsty-lang==0.8.5

From source:

git clone https://github.com/IAmSoThirsty/Thirsty-lang.git
cd Thirsty-lang
pip install -e .

Quick Start

module hello: core

glass greet(name) {
    return "hello, " + name + "!"
}

drink message = greet("governed world")
pour message

thirsty run hello.thirsty

The welcoming syntax is only the surface. The power appears when your program needs to touch something real — a file, a network call, a database write — and the runtime demands a proof before it lets that happen.

Architecture Map

flowchart LR
    Source[".thirsty source"] --> Parse["Parse + check"]
    Parse --> Mode{"core or governed?"}
    Mode -->|core| Run["ordinary runtime"]
    Mode -->|governed| Contracts["requires / ensures / invariant"]
    Contracts --> Policy["T.A.R.L. policy"]
    Policy --> Verdict{"ALLOW / DENY / ESCALATE"}
    Verdict -->|ALLOW| Effect["brokered effect"]
    Verdict -->|DENY| Refuse["fail closed"]
    Verdict -->|ESCALATE| Quorum["signed quorum path"]
    Effect --> Proof["proof record"]
    Refuse --> Proof
    Quorum --> Proof
    Proof --> Audit["hash-linked audit"]

Why Thirsty-Lang?

Most languages answer one question well: can this code execute?

Thirsty-Lang asks harder questions:

• Who is acting?
• What authority was proven?
• Which policy allowed it?
• What exact context was evaluated?
• What proof was produced?
• Can the audit chain detect tampering?
• Can a build target preserve governance, or does it have to confess the loss?
• Can an agent or tool adapter reach a side effect without crossing the broker?

That is the war surface now. Syntax still matters. Performance still matters. Ergonomics still matter. But governance is becoming part of the language runtime, not a document stapled to the side.

        source
          |
       parser
          |
   contracts + policy
          |
    ALLOW / DENY / ESCALATE
          |
       proof
          |
       audit
          |
   only then: effect

Governed Execution

Governed code declares contracts and then passes through policy before sensitive effects happen.

module bank: governed

glass withdraw(amt) requires amt > 0 ensures result >= 0 {
    return amt * 2
}

Runtime enforcement includes:

• 🧪 requires, ensures, and invariant checks
• 🚧 static and runtime blocking of governed calls from ordinary core mode
• 🧭 T.A.R.L. policy routing for governed calls and capability gates
• 🧾 proof-bearing ALLOW, DENY, and ESCALATE decisions
• 🛑 non-swallowable GovernanceViolation denials
• 🧯 fail-closed parsing for governed modules
• 📦 build refusal when a target would drop governance unless the loss is explicitly disclosed

T.A.R.L.: Policy As Resistance

T.A.R.L. is Thirsty's Active Resistance Language. It is a policy engine built around explicit verdicts, not optimistic defaults.

policy access_control

when user.role == "admin" => ALLOW
when action == "delete" and resource == "critical" => ESCALATE
when user.ip in blacklist => DENY
when true => DENY

Implemented policy surfaces include:

• 🌊 first-match-wins rule evaluation
• 🚦 ALLOW, DENY, and ESCALATE verdicts
• 🧪 sandboxed expression evaluation
• ⏱️ temporal policy windows
• 🔏 HMAC and Ed25519 proof certificates
• 🧷 strict proof verification flags for hardened use
• 🔁 replay, freshness, revocation, context, and policy-hash checks
• ⛓️ hash-linked audit archives with chain verification

Resistance Flow

sequenceDiagram
    participant Code as Thirsty code
    participant Runtime as Governed runtime
    participant TARL as T.A.R.L.
    participant Broker as Capability broker
    participant Audit as Audit archive

    Code->>Runtime: request governed call / side effect
    Runtime->>Runtime: evaluate contracts
    Runtime->>TARL: canonical context + authority
    TARL-->>Runtime: verdict + proof material
    alt ALLOW
        Runtime->>Broker: require capability
        Broker-->>Runtime: allowed decision
        Runtime->>Audit: append proof
        Runtime-->>Code: execute effect
    else DENY or ESCALATE
        Runtime->>Audit: append refusal proof
        Runtime-->>Code: fail closed
    end

Defensive Capabilities

Thirsty-Lang's defensive model is designed for hostile or ambiguous execution contexts: agents, plugins, generated code, local scripts, imports, and tool adapters.

The offensive challenge catalog is maintained in docs/THREAT_MODEL.md. The feature matrix is maintained in docs/STATUS.md.

The Six-Tier Stack

flowchart TB
    T6["Tier 6: TSCG-B<br/>binary frames + integrity"]
    T5["Tier 5: TSCG<br/>symbolic constraints"]
    T4["Tier 4: Shadow Thirst<br/>mutation resistance"]
    T3["Tier 3: T.A.R.L.<br/>policy + proof"]
    T2["Tier 2: Thirst of Gods<br/>OOP / async / structured errors"]
    T1["Tier 1: Thirsty-Lang<br/>lexer / parser / checker / runtime"]

    T6 --> T5 --> T4 --> T3 --> T2 --> T1

Unique Language Features

Thirsty-Lang uses its own vocabulary, but the names map to concrete execution behavior:

Example:

module counters: core

fountain Counter {
    drink count: Int = 0

    glass increment() {
        this.count = this.count + 1
        return this.count
    }
}

drink c = new Counter()
times 3 { pour c.increment() }

CLI Surface

Primary commands:

thirsty --help
thirsty run program.thirsty
thirsty fmt program.thirsty
thirsty build program.thirsty --target js
thirsty build program.thirsty --target js --policy policy.tarl --emit-manifest
thirsty prove program.thirsty --policy policy.tarl --emit-manifest
thirsty explain-denial program.thirsty --policy policy.tarl
thirsty govern program.thirsty
thirsty lsp

tarl --help
tarl eval policy.tarl --context '{"role":"admin"}'
tarl eval temporal-policy.tarl --context '{"role":"admin"}' --now 2026-07-01T12:00:00Z
tarl verify proof.json --ed25519-only
tarl audit verify-chain audit.db

shadow-thirst --help
tscg --help
tscg-b --help
thirst-of-gods --help

Proof-oriented commands are static unless explicitly documented otherwise:

• thirsty prove program.thirsty --policy policy.tarl --emit-manifest parses, checks, and emits a machine-readable proof-obligation report without executing program side effects. The report includes functions, imports, sensitive stdlib calls, governed calls, required TARL actions, required capabilities, context schema, authority requirements, contract obligations, proof mode, audit requirement, governance-loss status, and unresolved proof gaps. Required TARL actions include capability actions and governed function-call actions.
• thirsty explain-denial program.thirsty --policy policy.tarl emits a machine-readable explanation of missing policy, context, authority, and proof conditions for the static obligation set.
• thirsty build ... --emit-manifest --policy policy.tarl records source and policy hashes, required capabilities, context schema, proof/audit requirements, Shadow status when statically visible, and governance-loss status in the build manifest.

Explicit context schemas can be attached with --context-schema schema.json. The compact schema shape is:

{"fields": {"user.role": "string", "risk": {"kind": "number", "required": false}}}

T.A.R.L. verification is secure by default: tarl verify and ProofVerifier() reject unsigned proofs unless --allow-unsigned or ProofVerifier(require_signature=False) is used explicitly for local inspection. tarl eval refuses temporal policy windows and CURRENT_* builtins unless --now supplies the trusted evaluation time.

Evidence-First Claims

This project keeps defensive claims tied to files that can be inspected:

• status matrix: docs/STATUS.md
• adversary model and challenge catalog: docs/THREAT_MODEL.md
• governance runtime model: docs/governance_model.md
• grammar: docs/GRAMMAR.md
• language specification: docs/LANGUAGE_SPEC.md
• production acceptance tests: tests/test_production_acceptance.py
• offensive threat suites: tests/test_threat_model_broker.py, tests/test_threat_model_authority.py, tests/test_threat_model_audit_chain.py, tests/test_threat_model_failclosed.py

Run the main validation suite:

python -m pytest tests/ -q

Optional static and package checks:

ruff check src tests
mypy -p utf
python -m build

License

Apache-2.0. Copyright 2026 Thirsty's Projects LLC.

Security reports: FounderOfTP@thirstysprojects.com