Empirica

We Gave AI a Mirror. Now It Measures What It Believes.

Epistemic infrastructure for AI — measurement, memory, and calibration across sessions.

Empirica tracks what AI knows, gates what it does, and compounds learning across session boundaries. It measures the gap between what AI predicts and what's true — making AI agents measurably more reliable.

Training & Guides | CLI Reference | Architecture

Important: Empirica is an AI measurement framework. It has no cryptocurrency, token, coin, or blockchain component. Any token using the Empirica name (including "$EMPIRICA" on Solana) is unauthorized and not affiliated with this project or Empirica AI GmbH.

The Problem

AI coding agents today have no self-awareness about what they know:

Forgets between sessions — same questions, same dead ends, every time
Acts before understanding — edits your code without knowing the architecture
Can't tell you when it's guessing — no distinction between knowledge and confabulation
No audit trail — reasoning evaporates with the context window

What Empirica Does

Capability	What You Experience
Measures before acting	AI investigates your codebase before touching it. The Sentinel gate blocks edits until understanding is demonstrated
Remembers across sessions	Findings, dead-ends, and learnings persist in a 4-layer memory system. Session 3 starts where Session 2 left off
Prevents confident mistakes	The CHECK gate uses domain-aware thresholds scaled by criticality — cybersec/high is stricter than default/low
Shows confidence in real-time	Live statusline in your terminal: `[empirica] ⚡94% ↕70% │ 🎯3 │ POST 🔍92% │ K:95% C:92%`
Calibrates against reality	Three-vector model: self-assessed, observed (from deterministic checks), and AI-reasoned grounded state with rationale. Domain compliance loops iterate until all checks pass
Tracks your codebase	Temporal entity model auto-extracts functions, classes, and imports from every file edit — the AI knows what's alive and what's stale
Works through natural language	You describe tasks normally. The AI operates the measurement system automatically
Optional: coordinates with peer AIs	Cross-Claude mesh via Cortex (opt-in) — peer AIs propose work, ECO accepts/declines, completion handshakes carry commit SHAs. A persistent listener wakes idle sessions on inbox events. Empirica core works standalone without this — see Cross-AI Mesh below for the ecosystem layer

How You Use It

You talk to your AI normally. Empirica works in the background:

You:      "Fix the authentication bug in the login flow"

Empirica: [AI investigates → logs findings → passes Sentinel gate → implements fix → measures learning]

You see:  ⚡87% ↕70% │ 🎯1 │ POST 🔍85% │ K:88% C:82% │ Δ +K

You direct. The AI measures.

Empirica's CLI has 240+ commands spanning investigation, measurement, calibration, and memory — like a cockpit instrument panel. You don't need to learn any of them. The AI reads the instruments, operates the controls, and reports back in natural language. The statusline gives you the flight data at a glance.

For power users, direct CLI access is always available: empirica goals-list, empirica calibration-report, empirica project-search --task "...", and more.

Learn the full workflow: getempirica.com has interactive training, guides, and deep explanations of every concept.

Quick Start

Install + Claude Code (Recommended)

pip install empirica
empirica setup

Then just start working. The hooks, Sentinel, system prompt, statusline, and MCP server are all configured automatically.

empirica setup --harness picks the harness. It resolves from --harness, else $EMPIRICA_HARNESS, else claude-code. An unsupported harness is refused by name and nothing is written — previously it wrote ~/.claude/ regardless and reported success, which on any other harness configured a path that harness never reads.

Codex is refused deliberately: ecodex is self-provisioning (it vendors the plugin into its own binary), so there is nothing here to write, and the refusal points you at that pipeline. setup-claude-code remains as an alias and pins claude-code regardless of environment.

See Claude Code Setup for details — including a "What the hooks inject" section for Claude sessions that want to see the contract (which hook fires when, what it adds to the AI's context, source pointers for every emission) before agreeing to install.

Already have Claude Code configured? Use --force to replace your default Claude Code settings with Empirica's epistemic hooks. Without --force, setup only writes files that don't already exist — so if you've already used Claude Code, the default internals stay in place and Empirica's hooks won't activate.

empirica setup --force

--force replaces hooks in settings.json but only removes Empirica's own hooks — hooks from other plugins (Railway, Superpowers, etc.) are preserved.

Alternative Installation Methods

Homebrew (macOS)

brew tap empiricaai/tap
brew install empirica
empirica setup

Docker

# Security-hardened Alpine image (~276MB, recommended)
docker pull nubaeon/empirica:1.13.36-alpine

# Standard image (Debian slim, ~414MB)
docker pull nubaeon/empirica:1.13.36

# Run
docker run -it -v $(pwd)/.empirica:/data/.empirica nubaeon/empirica:1.13.36 /bin/bash

Manual / Other AI Platforms

pip install empirica
pip install empirica-mcp        # MCP Server (for Cursor, Cline, etc.)
cd your-project && empirica project-init

The CLI works standalone on any platform. The full epistemic workflow (epistemic transactions, Sentinel, calibration) requires loading the system prompt into your AI — the easiest path is empirica setup, which wires the lean prompt into ~/.claude/empirica-system-prompt.md and references it from your ~/.claude/CLAUDE.md. See Claude Code Setup for details.

First Session

empirica onboard   # Interactive walkthrough of the full workflow

Or just start working — with Claude Code hooks active, the AI manages the epistemic workflow automatically.

The Measurement Architecture

Empirica works through nested abstraction layers:

Plan
 └── Transaction 1 (Goal A)
      ├── NOETIC: investigate, search, read → findings, unknowns, dead-ends
      ├── CHECK: Sentinel gate → proceed / investigate more
      ├── PRAXIC: implement, write, commit → goals completed
      └── POSTFLIGHT: measure learning delta → persists to memory
 └── Transaction 2 (Goal B, informed by T1's findings)
      └── ...

Plans decompose into transactions — one per goal or Claude Code task. Each transaction is a noetic-praxic loop: investigate first (noetic), then act (praxic), with the Sentinel gating the transition. Along the way, the AI collects and reads artifacts (findings, unknowns, assumptions, dead-ends, decisions) while using semantic search to surface relevant epistemic patterns and anti-patterns from the project's history. Top artifacts are ranked by confidence and fed into each project's MEMORY.md as a hot cache.

The Epistemic Transaction Cycle

PREFLIGHT ────────► CHECK ────────► POSTFLIGHT
    │                 │                  │
 Baseline         Sentinel           Learning
 Assessment        Gate               Delta
    │                 │                  │
 "What do I      "Am I ready      "What did I
  know now?"      to act?"         learn?"

PREFLIGHT: AI assesses its knowledge state before starting work. CHECK: Sentinel gate validates readiness before allowing code edits. POSTFLIGHT: AI measures what it learned, creating a delta that persists.

Live Statusline

With Claude Code hooks enabled, you see the AI's epistemic state in real-time:

[empirica] ⚡94% ↕70% │ 🎯3 ❓12/5 │ POST 🔍92% │ K:95% C:92% │ Δ +K +C

Signal	Meaning
⚡94%	Overall epistemic confidence
↕70%	Sentinel threshold (know gate) — user-facing only
🎯3 ❓12/5	Open goals (3), unknowns (12 total, 5 blocking)
POST 🔍92%	Transaction phase + work state (🔍 investigating / 🔨 acting) with composite score
K:95% C:92%	Knowledge and Context vectors (color-coded by gap to threshold)
Δ +K +C	Learning delta (POSTFLIGHT only) — which vectors improved

The 13 Epistemic Vectors

These vectors emerged from 600+ real working sessions across multiple AI systems. They measure the dimensions that consistently predict success or failure in complex tasks.

Tier	Vector	What It Measures
Gate	`engagement`	Is the AI actively processing or disengaged?
Foundation	`know`	Domain knowledge depth
	`do`	Execution capability
	`context`	Access to relevant information
Comprehension	`clarity`	How clear is the understanding?
	`coherence`	Do the pieces fit together?
	`signal`	Signal-to-noise in available information
	`density`	Information richness
Execution	`state`	Current working state
	`change`	Rate of progress/change
	`completion`	Task completion level
	`impact`	Significance of the work
Meta	`uncertainty`	Explicit doubt tracking

Deep dive: Epistemic Vectors Explained

How It Works With Claude Code

Empirica doesn't replace or reinvent anything Claude Code already does. Claude Code owns tasks, plans, memory, and projects. Empirica adds the measurement layer on top:

Claude Code Does	Empirica Adds
Task management	Epistemic goals with measurable completion
Plan mode	Investigation phase with Sentinel gating — no edits until understanding is verified
MEMORY.md	Auto-curated hot cache ranked by epistemic confidence
Context window	4-layer memory that survives compaction and persists across sessions
Code editing	Grounded calibration — was the AI's confidence justified by test results?
Subagent spawning	Bounded autonomy with delegated work counting and budget tracking

The result: Claude Code's native capabilities, enhanced with measurement, gating, and calibration feedback that compounds over time.

16 skills ship with the plugin — the transaction discipline, graph gardening, the quality sweep, mesh messaging, and more. They are lazy: a skill does nothing until it loads, so knowing when each fires matters more than knowing what it holds. → Skills reference

Cross-AI Mesh (Optional Ecosystem Layer)

This section describes an optional layer. Empirica core — measurement, calibration, artifacts, goals, project-search, sentinel gating — works fully standalone. The mesh is an opt-in capability for users who run multiple Claude sessions across projects and want them to coordinate as peers. If you only use one AI in one repo, skip this section.

The mesh runs on top of Empirica Cortex (proprietary serving layer) plus an optional browser extension for ECO triage. At a high level:

empirica AI ── proposes work ──► ECO Accept/Decline ──► peer AI wakes + acts
                                                             │
                              completion handshake (commit SHA)
                                                             │
empirica AI ◄────────── outbox/completed event ──────────────┘

Capability	What it does
Mesh proposals (two flavors)	A noetic flavor is auto-accepted (FYI / question / discussion). Praxic flavors (code change / architecture / investigation) are ECO-gated — they wait for an Accept/Decline decision before the target AI acts
`empirica mailbox reply`	One CLI verb closes the AI-to-AI handshake atomically — single-step completion ack instead of two
Persistent listener service	systemd-user / launchd daemon holds a push stream open. Idle sessions wake the moment a peer's proposal is decided, not on next user prompt
Canonical loops (opt-in)	Wake-on-event is the standing trigger, so nothing is scheduled by default. Inbox polling (30s adaptive) exists for harnesses that cannot do wake-on-event, and daily housekeeping is a cron loop — both are opt-in, registered with `empirica loop register`. See Trigger Model

The browser-side ECO surface (Accept/Decline, inbox triage, publish review) lives in the proprietary Empirica Extension. The full API surface for proposals, listener events, and the trust pipeline is documented at getempirica.com.

Mesh + Shared Epistemic Record

Requires Empirica Cortex (proprietary). Everything in this section — mesh proposals, the persistent listener, the Shared Epistemic Record, and the empirica mesh command cluster — is a Cortex-served layer. It is not available in empirica core on its own; without Cortex, empirica is a single-AI measurement layer.

The cross-AI coordination layer. Practitioners in different practices coordinate not via text-only chat but via epistemic envelopes that carry calibrated state, source-tagged provenance, noetic/praxic intent, and workflow position.

Practitioner / practice framing — practices are calibrated epistemic specializations that persist; practitioners (the LLMs) are fungible. See MESH_CONCEPTS.md.
Shared Epistemic Record (SER) — cortex-resident shared-state object for coordination across ≥2 practitioners. Goals stay per-practitioner; SER carries the joint state (coordination_state, role-tiered participants, escalate-on-silence). Three actions: create_ser / transition_ser / ser_ack. Spec at empirica-cortex/docs/architecture/SHARED_EPISTEMIC_RECORD.md.

empirica mesh command cluster — unified diagnostic + control surface across listener instances + the optional cortex bridge:

empirica mesh status              # per-instance health (local + cortex bridge)
empirica mesh diagnose <ai_id>    # deep diagnostic + suggested fix command
empirica mesh restart <ai_id>     # systemd/launchd restart + verify
empirica mesh on|off <ai_id>      # install + start | stop the listener
empirica mesh tail [<ai_id>]      # live-tail loop_fires.log

Listener self-heal — in-process watchdog terminates stale curl streams (TCP-zombie detection at 120s by default); HTTP 429 detection applies long backoff with catch-up poll continuing during the window.
Mesh Routing Protocol v0 locked four-way with cortex + extension + mesh-support. L1/L2/L3 trust model, server-stamped layer annotation, participant-scoped thread reads.

Without Cortex, empirica is a single-AI measurement layer — the proposals, listener, SER, and empirica mesh cluster above are all Cortex-dependent. Core does ship a minimal local empirica message-* git-notes primitive for passing notes between your own sessions, but that is note-passing, not the coordinating mesh. Everything that makes empirica valuable on its own — measurement, calibration, artifacts, goals, project-search, sentinel gating — works fully standalone.

Practice Model + Entity Graph

Empirica's workspace stores entities (projects, contacts, organisations, engagements, users) in entity_registry with typed edges in entity_memberships. The Practice Model frames this consistently:

Term	Maps to
Practitioner	the AI working on the project (you)
Practice	the empirica project itself
Agent	a subagent spawned during the work

Four CLI verbs query the graph without raw SQL:

empirica entity-list [--type project|contact|organization|engagement|user]
empirica entity-show <type:id>          # full record + incoming/outgoing edges
empirica entity-walk <type:id> --depth 3 # BFS membership graph, cycle-safe
empirica entity-search "query" [--type T]

All read-only, all support --output json. Backs cross-project orchestration, CRM workflows, and the entity-aware POSTFLIGHT retrospective.

Platform Support

Two harnesses are supported. Everything else is untested — prompt and rules files may exist for other tools, but their presence is not support, and we would rather say so than let you find out mid-project.

Harness	Status	What you get
Claude Code	Supported	Full integration — plugin, hooks, Sentinel gate, skills, agents, statusline, MCP
Codex (via ecodex)	Supported	Self-provisioning: ecodex vendors the plugin into its own binary and loads hooks natively. `empirica setup` refuses codex by name and points you at ecodex's pipeline — that refusal is correct, not a gap
Antigravity (Google), Vibe (Mistral AI)	Not yet	Possible future support. Not now
Everything else	Untested	The CLI works anywhere Python does, but no harness integration is verified

MCP is a fallback, not a second path

empirica-mcp exists for harnesses that cannot run the CLI integration — Claude Desktop, Gipitee-style clients. Use it when you have no alternative.

The reason matters: an MCP surface cannot enforce the Sentinel gate the way a blocking pre-tool hook does. So an MCP-only deployment gives you the measurement layer with a weaker guarantee — the noetic/praxic firewall becomes advisory. That is a real difference in what the system promises, and it should be a deliberate choice rather than something you infer from a feature table.

Documentation & Training

Resource	What It Covers
getempirica.com	Training course, interactive guides, deep explanations
Natural Language Guide	How to collaborate with AI using Empirica
Getting Started	First-time setup and concepts
CLI Reference	All 240+ commands documented
Architecture	Technical reference for contributors
Claude Code Setup	Install + system prompt + plugin wiring
Changelog	Full release history — every version since 1.0
Upgrade to 1.13	Migration guide for the 1.12.x → 1.13 jump — two deliberate breaking changes, both fail-safe. Older guides (1.9–1.11) live in docs/guides/

The Empirica Ecosystem

Project	Description	Status
Empirica	Core measurement system — epistemic transactions, Sentinel, calibration, 13 vectors	Open source (MIT)
Empirica Iris	Epistemic browser automation with SVG spatial indexing — Sentinel gating for visual interactions	Open source (MIT)
Docpistemic	Epistemic documentation coverage assessment — know what your docs know	Open source (MIT)
Breadcrumbs	Survive context compacts with git notes — dead simple session continuity	Open source (MIT)
Ecodex	Codex-based Rust harness — the epistemic firewall and pattern hunt, native to Rust/cargo (clippy, `cargo check`/`test`/`audit`)	Open source (Apache-2.0)
Eat the Broccoli	Portable quality-and-pattern audit — deterministic tooling plus a learned-pattern hunt for the failure classes that pass every test and still ship broken	Open source (MIT)
Empirica Cortex	Cross-project intelligence layer — serves verified predictions and accumulated learnings to condition future work	Proprietary
Empirica Workspace	Entity Knowledge Graph, Epistemic Prompt Engine, CRM, portfolio dashboard	Proprietary
Empirica Extension	Chrome extension — desktop face of the mesh. ECO Accept/Decline, inbox/outbox triage, publish review, conversation extraction from Claude.ai / ChatGPT / Gemini / Grok	Proprietary
Empirica Outreach	Voice-aware outreach + publishing — prosody-matched content generation and multi-channel dispatch	Proprietary

Building something with Empirica? Open an issue to get listed.

The Empirica Foundation

The Empirica Foundation stewards the open ecosystem — the public projects above and the community growing around them — keeping the commons healthy as it scales.

The open-source projects are free for everyone. What the Foundation adds is a seat at the table: contributors who help build the community get to use the rest of the ecosystem too — the otherwise-paid layers (Cortex, Workspace, the Extension) and the collaborative mesh that lets practitioners coordinate as peers. Build the commons, use the whole thing.

Want in? Open an issue or a PR with your reasons — that's the whole application. Everyone who wants to help shape where this goes is welcome.

What's New in 1.13.36

The criterion vocabulary can finally say what practitioners were already trying to say. Measured across 59 practice databases: 5,462 of 5,484 success criteria (99.6%) carried validation_method: completion — including 2,473 authored conditions like SSH password auth disabled that no subtask ratio can judge. The field was degenerate, not unused: one value because there was one choice. New methods, derived from a corpus pass rather than invented: tests_pass (test_pass_rate ≥ threshold), committed (commit_count ≥ threshold — a count, not a ratio), artifact_exists (the description IS a path), and prose / undetermined so an uncheckable done-condition is declared rather than stamped with a lie. Two derived axes deliberately absent, pinned by test: count_threshold is quality_gate under another name, and no_regression needs baseline machinery that does not exist. Every new evaluator is observed both passing and FAILING in tests, and absent evidence (no pytest report, work outside git) skips with a reason — never a pass, never a confident wrong answer.
/pre-action-grounding skill — the protocol's core-side surface. Decompose → investigate → grade (read/ran/retrieved/assumed, the CHECK vocabulary reused) → ask only the load-bearing assumed residue (0–2 questions) → bank the rest as assumption-log → emit a goal whose criteria are typed where an evaluator reaches and honestly prose where none can. Built for requesters who don't volunteer the why or the done-condition; the Cowork half ships from cortex on the same substrate.
provides.declined — a practice can say what it is NOT for. requires got a third state; provides did not, so an exclusion could only be a YAML comment. The wrong answer costs more here: a wrong requires produces a missing file that fails at first use, a wrong provides produces a misroute that fails silently for as long as the sender is patient. A standards-submission deadline was escalated to a remote-ops practice, correctly addressed and entirely misrouted, and sat for a day looking coordinated. Same rules as the requires block — reason required, an axis cannot be both provided and declined — and the positive state now reads back as provides rather than consumes, with side= to disambiguate skills, which exists on both blocks meaning different things.
The Sentinel firewall could wedge with its own remedy denied. Two halves of one observed incident. PREFLIGHT returned ok: true with a transaction_id while the active_transaction*.json — the firewall's ONLY input — was never written: the write sat behind except → logger.debug("…non-fatal…"), so the gate stayed pinned to a stale closed transaction and denied every praxic call with run new PREFLIGHT, blaming the practitioner for the thing they had just done. The write now raises on an unresolvable path, is verified through the surface the firewall actually reads, and a failure rides out on the response as firewall_warning with impact and recovery. And the deny's named remedy was itself denied: the allow-list matched literal prefixes, so empirica --verbose preflight-submit - — the exact escape hatch, with the flag someone debugging adds — failed every prefix. Global flags are now stripped before the tier match (only the three real ones, only leading, with a negative control so --wat still fails).
A command that printed an error could exit 0. handle_cli_error returns None and the dispatcher mapped None to success; an AST walk found 107 of 152 call sites reporting an error and then falling off the end of their except block. Observed twice on goals-create alone: a rejected criterion and a UNIQUE-constraint save failure, both ❌-printed, both rc 0 — a scripted caller records a goal that does not exist. Fixed at the boundary (the report is recorded; the dispatcher fails closed on it), not per-handler — patching 107 leaves the 108th to be written wrong. Explicit returns still win, ok: true still wins, broken pipes stay exempt, and the record scopes to one dispatch so residue from an earlier in-process command cannot fail a later clean one.
completion criteria stopped over-claiming. SubtaskCompletionEvaluator. applies() was return True, so every authored prose criterion was scored as a subtask ratio — the mechanical cause of the task completion 0% vs threshold 100% nudge that fired on ~15 consecutive POSTFLIGHTs and was rightly ignored: it was structurally incapable of saying anything else. It now claims only the auto-filled sentinel, metric-named descriptions, and explicit thresholds; an unmatched dispatch reports passed: false, skipped: true instead of passed: true, because an unchecked criterion is not a met one. The vocabulary itself is now ONE constant consumed by both validators (CLI and MCP) with a test against a second literal copy reappearing.
A project UUID skipped cross-project routing entirely. The guard was not _is_uuid(project_id), so passing a project's canonical UUID — the most precise identifier, the one you reach for when you want certainty — was the single form that got no routing. The row was written to the CALLER's database, correctly stamped with the target's project_id, so a caller-side read-back keyed on project_id passed while a session inside the target project read its own sessions.db and never saw the artifact. A peer's prevention experiment ran cold because the primed subject was never exposed to a prior they had verified. A UUID now routes exactly like a name; a UUID that IS the local project's own id stays local, since an unregistered local project is a normal state.
A write whose session-project differs from the cwd-project now says so. A naked finding-log from inside a different registered project writes to the session's project while the stale-mapping guard logs "trusting cwd" — two ground truths, and a peer got a real foreign-context row in their graph. Which should win is a design question and is deliberately not settled here; what changed is that the divergence is no longer silent.

Privacy & Data

Your data stays local:

.empirica/ — Local SQLite database (gitignored by default)
.git/refs/notes/empirica/* — Epistemic checkpoints (local unless you push)
Qdrant runs locally if enabled

No cloud dependencies. No telemetry. Your epistemic data is yours.

Community & Support

Website: getempirica.com
Issues: GitHub Issues
Discussions: GitHub Discussions

License

MIT License — see LICENSE for details.

Author: David S. L. Van Assche Version: 1.13.36

Turtles all the way down — built with its own epistemic framework, measuring what it knows at every step.

Release files for empirica 1.13.36

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for empirica 1.13.36
File	Size	Uploaded
empirica-1.13.36.tar.gz	2.6 MB	Sep 3, 2026	Details

Built distribution (wheel)

Table of built distributions (wheels) for empirica 1.13.36
File	Interpreter	ABI	Platform	Reset
empirica-1.13.36-py3-none-any.whl 2.6 MB Sep 3, 2026	Python 3	none	any	Details

Total release size: 5.2 MB

Release files / empirica-1.13.36.tar.gz

Download URL	empirica-1.13.36.tar.gz
Size	2.6 MB
Tags	Source
SHA-256 checksum How to use checksums	`937cb8496f6d91a6ecff16f907907a9071e62e8ff09d154776cc71e0edee748e`
BLAKE2b-256 checksum How to use checksums	`2e6600c2e7d48ef56e30730dcfdb76a7102f7cf5c9f3de4f01f91ea90e38a7ab`
Upload date	Sep 3, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	Yes
Uploaded via	`twine/7.0.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.

Identity

Publishing platform: GitHub Actions
Publishing repository: github.com/EmpiricaAI/empirica
Publishing commit: github.com/EmpiricaAI/empirica/tree/b7575fa8b327dc2ee206ed0660bb11d6f60f7f32

Workflow

Publishing configuration: github.com/EmpiricaAI/empirica/blob/b7575fa8b327dc2ee206ed0660bb11d6f60f7f32/.github/workflows/release.yml
Publishing logs: github.com/EmpiricaAI/empirica/actions/runs/33810304630/attempts/1

Artifact

Subject: empirica-1.13.36.tar.gz
SHA-256 checksum: 937cb8496f6d91a6ecff16f907907a9071e62e8ff09d154776cc71e0edee748e Verifying attestations

Release files / empirica-1.13.36-py3-none-any.whl

Download URL	empirica-1.13.36-py3-none-any.whl
Size	2.6 MB
Tags	Python 3
SHA-256 checksum How to use checksums	`0e28dd464d86eefa8be4d6740b2e77cf9dd125cff5df06d057e75e9f74526da4`
BLAKE2b-256 checksum How to use checksums	`c3deb4ce3fc08dcf8e05a2add36561aa64c622020dae71f8a38813c0b208bc1b`
Upload date	Sep 3, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	Yes
Uploaded via	`twine/7.0.0 CPython/3.13.14`

Provenance

Identity

Publishing platform: GitHub Actions
Publishing repository: github.com/EmpiricaAI/empirica
Publishing commit: github.com/EmpiricaAI/empirica/tree/b7575fa8b327dc2ee206ed0660bb11d6f60f7f32

Workflow

Publishing configuration: github.com/EmpiricaAI/empirica/blob/b7575fa8b327dc2ee206ed0660bb11d6f60f7f32/.github/workflows/release.yml
Publishing logs: github.com/EmpiricaAI/empirica/actions/runs/33810304630/attempts/1

Artifact

Subject: empirica-1.13.36-py3-none-any.whl
SHA-256 checksum: 0e28dd464d86eefa8be4d6740b2e77cf9dd125cff5df06d057e75e9f74526da4 Verifying attestations