The common language every module in the stack shares — without framework coupling

Every Quarkus module eventually asks the same questions: who is the current user? What is the preference value for this case type? How do I express a scope path? casehub-platform answers those questions once, in pure Java, with no Quarkus dependency on the answer.

That constraint matters more than it sounds. If the common types live in a framework-coupled layer, every module that depends on them pulls the framework with it. The platform-api has no Quarkus dependency, no CDI, no JPA — so it is a safe transitive dependency at any tier, including pure domain modules that should never touch infrastructure.

Quarkus integration is opt-in. Add the config module and preferences become scope-aware YAML — values that vary per case type and per installation, resolved per-request, without restarting the application. Add the oidc module and the current principal is backed by a real JWT. Leave both out and mock @DefaultBeans activate automatically in dev and test. The memory layer adds a semantic fact store with GDPR Art.17 erasure — the same zero-coupling pattern, with PostgreSQL, SQLite, or in-memory adapters.

View on GitHub ↗

An agentic system makes claims. The ledger is what proves they happened.

An agent says it analyzed a transaction, found nothing suspicious, and moved on. In a regulated setting, "the agent said so" is not a compliance record. The ledger is.

Every write is immutable. Entries chain via Merkle tree operations — the same construction as certificate transparency logs — so any third party can verify that a specific record exists and hasn't been altered, without trusting the system that produced it. GDPR Art.17 erasure is supported: the identity token is severed, not the record. The audit chain survives; the PII does not.

The trust-scoring layer tracks how reliable each agent is, per capability and per domain, using a Bayesian model that updates from outcomes. An agent with a strong record in SAR drafting accumulates a higher trust score there than one with a checkered history. Routing decisions downstream can use that signal — and the scores improve automatically as the system accumulates evidence, without any manual calibration.

View on GitHub ↗

Work that routes itself — labels, queues, and rules that do the triage for you

Work arrives in a pile. Someone has to read it, decide what it is, figure out who handles it, and move it to the right team. In a high-volume or regulated system, that manual triage is where delays happen, mistakes happen, and accountability breaks down.

casehub-work flips that. WorkItems carry metadata labels, and labels drive filters. Set a label on a WorkItem — pep-detected, grade-4, senior-review-required — and the right filter picks it up, the right queue surfaces it to the right team, automatically. Business rules set labels based on conditions: content, elapsed time, priority, source. The routing happens without a human in the decision loop.

Once in a queue, the usual guarantees apply: SLA deadlines with escalation targets, delegation chains with full ownership history, and an append-only audit trail per item. The assigneeId is a string — a human identity, an AI agent, or both in sequence. When a deadline expires, a CDI event fires in the same database transaction as the breach. No polling, no eventual consistency, no race condition.

View on GitHub ↗

The agentic mesh — structured channels, formal obligations, humans and agents on equal footing

Multi-agent coordination without a proper communication layer is API calls and inference. You can see what agents produced; you can't see what was asked, what was promised, or whether the promise held. Qhorus makes those things formal — every interaction is a typed act with a ledger record and, when appropriate, a commitment that has to be discharged.

The channel is the core concept. A case isn't one conversation — it's several running in parallel, with different participants and different rules. Agent coordination, status monitoring, human governance: these belong in separate channels because they have different semantics. The channel defines who can write to it, what message types are permitted, and how delivery works.

The standard layout for a case is three channels. The work channel is where agents receive tasks and report completion — prescriptive, task-oriented. The observe channel is where state changes are broadcast and passive monitoring happens — dashboards, other agents, audit systems can watch without participating. The oversight channel is where humans govern: approving decisions, rejecting proposals, asking questions that require answers before work continues.

Human participation is first-class, not a side door. A compliance officer who receives a task via the oversight channel has the same obligation lifecycle as an AI agent — the same commitment record, the same deadline, the same breach if they don't respond. Their reply, however it arrives — email, Slack, any connected channel — is translated into a formal response that discharges the obligation and writes a ledger entry. Qhorus doesn't distinguish between human and agent participants. It only distinguishes between those who honored their commitments and those who didn't.

Humans don't have to read every raw message in a channel to know what's happening. The ChannelProjection SPI folds channel history into digest views — vote tallies, review manifests, summaries — derived deterministically from the message stream. The oversight channel becomes something a human can actually act on, not a firehose to wade through.

Beneath all of this is a single Dispatch Gate — the only path through which a message can enter a channel. There is no side door. The gate enforces access control, rate limiting, and records every message to the tamper-evident ledger before fan-out. When an agent sends a task, the system creates a formal obligation. If the recipient completes it, that obligation closes. If they don't respond by the deadline, a watchdog fires. If they hand it off, the obligation transfers. These aren't abstract categories — they're the mechanism by which "agent X was told to do Y and didn't" becomes a fact in the ledger rather than an inference from logs.

View on GitHub ↗

When a WorkItem escalates, something has to actually reach the compliance officer

casehub-connectors is the straightforward part: a unified Connector SPI with built-in implementations for Slack, Teams, Twilio SMS, WhatsApp, and email. One dependency, five channels.

The integration with Qhorus is what makes it more than a notification library. The connector-backend module bridges inbound messages — a human replying to a Slack message or email — back into Qhorus channels as formal speech acts. A compliance officer replies to a notification; that reply enters the oversight channel as a RESPONSE, discharges the commitment, and writes a ledger entry. The human never touches the system directly. The system sees a formal act regardless.

The implementation is deliberate. Pure java.net.http.HttpClient for every HTTP-based connector — no Camel, no vendor SDK, no additional framework pulling in its own dependency tree. Custom connectors are CDI beans — implement the interface, annotate it @ApplicationScoped, and it's discovered automatically.

View on GitHub ↗

Agents need to know who they are, what they can do, and what they're allowed to say

Unstructured agent identity is a coordination problem. If agents self-describe in free text, routing decisions are guesswork. If system prompts are hand-written per deployment, they drift from what agents actually do. Eidos gives the infrastructure layer of agent identity a formal home — without touching LLM implementation.

Agents register with a structured descriptor: an identity, a slot in the system, capability tags, a disposition, and domain confidence scores. Other components discover agents by slot or capability — deterministically, not by asking the LLM who's available. System prompts are rendered from these descriptors, so agents operate within their declared scope on every invocation.

The confidence scores aren't static. casehub-neural-text's ScalarRegressor can estimate actual epistemic confidence from agent output history and feed those estimates back into Eidos. An agent that consistently performs well in the safety-monitoring capability accumulates a higher score over time. Routing decisions improve without manual recalibration.

View on GitHub ↗

The inference primitives LangChain4j doesn't give you — running locally, no API required

LangChain4j gives you dense embeddings, document parsing, chunking, and a retrieval pipeline. It doesn't give you hallucination detection, action risk scoring, or sparse retrieval that can find "ICH E6" rather than something semantically related to it. In regulated deployments — clinical, AML, financial — "semantically related" isn't close enough, and data cannot leave the tenant's infrastructure.

casehub-neural-text fills that gap with five ONNX model types, all running in-process via ONNX Runtime JVM. NLI models score LLM output for faithfulness against the input facts before assertions enter the shared fact space — hallucinations are caught before they propagate downstream to rules or other agents. A TextClassifier decides whether an action proceeds autonomously or routes to human oversight. A ScalarRegressor estimates epistemic confidence and feeds it back to Eidos. SPLADE sparse embeddings handle the lexical precision that dense vectors sacrifice.

The RAG layer wires LangChain4j's retrieval pipeline to casehub tenancy: named, isolated document corpora, hybrid dense+sparse search via Reciprocal Rank Fusion. The corpus for an AML investigation and the corpus for a clinical trial are completely isolated — enforced at the SPI boundary, not by convention.

View on GitHub ↗

Not a workflow engine. Workers react to shared state — the engine doesn't tell them what to do.

Workflow engines define sequences. Step A finishes, step B starts. That works until the world doesn't cooperate — an adverse event arrives while eligibility screening is still running, a Grade 4 signal hits three sites simultaneously, a security finding changes the architecture review priority. Sequence-based coordination requires branching logic for every exception.

The engine uses a different model: Modernised Blackboard Architecture. Workers declare their trigger conditions and capability contracts. The Reactor records context changes and notifies workers that match — it never executes tasks or makes routing decisions itself. When a clinical trial hits a Grade 4 adverse event that simultaneously requires an IRB consultation and a DSMB rollup, those things happen in parallel because three workers react to the same context change. No branching code. Just conditions and workers.

Cases are bounded by goals, not by steps. A case completes when its goals are met, whether that took one worker or twenty and whether the path was predictable or not. Workers can be Java lambdas, Serverless Workflow DSL, LangChain4j AI services, or human tasks via casehub-work.

View on GitHub ↗

Remote Claude sessions, a live mesh dashboard, and MCP access — from one binary

Claudony is where the harness meets the human operator. It runs Claude Code CLI sessions remotely via tmux, surfaces the Qhorus message mesh in a browser dashboard, and exposes session management to a controller Claude instance via MCP. Two modes from one binary: server mode owns the sessions; agent mode becomes an MCP endpoint that a controller Claude can drive programmatically.

The session layer is deliberately simple. tmux is the source of truth — on restart, the registry repopulates from live sessions rather than from a database. The CaseHub wiring is a clean SPI implementation layer: Claudony provisions tmux sessions as CaseHub workers, creates Qhorus channels per case, builds startup prompts from ledger lineage, and maps tmux lifecycle events to CaseHub worker states. None of that logic is entangled with session management.

Nothing in the ecosystem depends on Claudony. It's the integration terminus — the place where Claude sessions, Qhorus channels, and a browser dashboard converge.

View on GitHub ↗

OpenClaw's skill ecosystem, CaseHub's accountability layer — wired together

OpenClaw agents have pre-built skills: banking APIs, calendar access, smart home integration, messaging. CaseHub has the formal accountability layer: SLA enforcement, commitment tracking, tamper-evident audit. The problem is that neither is much use in a regulated setting without the other. casehub-openclaw bridges them.

OpenClaw agents are provisioned as CaseHub workers through the standard WorkerProvisioner SPI — no special treatment, no custom coordination code. Qhorus channels wire bidirectionally to OpenClaw's hook API so speech-act obligations and ledger records apply to OpenClaw actions just as they would to any other worker.

The ChannelContextWindow is where the integration pays off. It's a short-term buffer of recent Qhorus channel activity, injected into every OpenClaw agent turn at the system prompt level. Agents know what the other agents in the mesh have been observing — not just their own history. That shared awareness is what turns a collection of agents into a coordinated system.

View on GitHub ↗

PR review where every finding is traceable and every missed one is accountable

Most AI code review is a linter with a chat interface: you paste the diff, you get a response, and that response is the entire record. devtown is different. Security, architecture, and test-coverage specialists are separate agents, routed by the actual content of the change — not randomly assigned, not always invoked. SLA gates prevent reviews from sitting indefinitely. And the review record is tamper-evident: every finding, every routing decision, every specialist invocation is in the ledger.

When the same commit slips through security review and causes a production incident, the audit trail shows whether the security agent was dispatched, what it returned, and whether the finding was acknowledged. That accountability runs both ways — it protects the team that ran the review and gives the post-mortem something real to work with.

devtown is the first application layer built on the full CaseHub foundation and a reference implementation for how to build domain-specific harnesses on top.

View on GitHub ↗

FinCEN requires an auditable evidence chain per finding. Most agentic AML systems can't provide one.

Current agentic AML systems coordinate agents via API calls. One agent calls another, gets a response, and the sequence moves on. The audit trail is whatever you can reconstruct afterward. FinCEN requires more than reconstruction — it requires a causal chain from each finding to the evidence that produced it, tamper-evident, independently verifiable. casehub-aml produces that record as a structural consequence of how the investigation runs, not as a reporting step bolted on at the end.

Investigation paths adapt to the case. An entity with high risk and PEP detection follows a different path than a low-risk transaction — not because branching logic was written for every scenario, but because casehub-engine's binding rules react to the context. The compliance officer review is a WorkItem with a 30-day FinCEN SLA and a named escalation target.

The tutorial is seven layers, each adding a single foundation module and showing concretely what breaks without it. Java developers in financial services can adopt incrementally without rebuilding from scratch at any step.

View on GitHub ↗

GCP, FDA, and EMA requirements aren't a checklist — they're structural constraints the architecture has to satisfy

A serious adverse event requires documented medical review within 24 hours under GCP. PI authorisation for a protocol deviation is a formal act — it has to be traceable to a named investigator. A consent withdrawal under GDPR Art.17 has to leave the audit trail intact while removing the PII. These are not requirements you satisfy by adding logging. They constrain how the system is built.

casehub-clinical coordinates eligibility screening agents, safety monitoring agents, PI authorisation gates, and IRB approval gates across multiple trial sites. Adverse event WorkItems carry CTCAE grading and 24-hour SLA enforcement. PI authorisation is a COMMAND with a formal commitment lifecycle — if the named investigator doesn't respond, that's a recorded breach. Multi-site coordination uses sub-cases with a trial-level blackboard: a Grade 4 event at one site updates shared state that the DSMB rollup observes across all sites.

The tutorial is eight layers starting from naive Java, each demonstrating what GCP or FDA requirement breaks without the next module.

View on GitHub ↗

The same foundation that coordinates clinical trials also runs a StarCraft II game at millisecond resolution

StarCraft II runs at 22.4 game frames per second. Decisions about supply, expansion, and engagement happen in hundreds of milliseconds. That's a stress test for any coordination framework: if the abstraction layer can't keep up, it's not a general-purpose harness — it's an enterprise CRUD tool with aspirations.

QuarkMind answers that question directly. The Modernised Blackboard Architecture holds at real-time game speed. The same shared fact space that coordinates a clinical trial safety monitor and an IRB consultation gate also runs a Protoss economics agent, a Drools-powered strategy layer, and a GOAP tactics planner — concurrently, against a real opponent, within the game's frame budget.

The plugin architecture is the interesting part. Each concern — economics, strategy, tactics, scouting — is a CDI interface. Swap in a Drools Rule Unit for the strategy layer, or a LangChain4j agent, or a hand-coded planner. The platform picks it up automatically.

View on GitHub ↗

Most personal automation is best-effort. A reminder fires and then nothing enforces what follows.

An agent says it will follow up with the contractor. Whether it does is unclear — and if it doesn't, there's no record that the follow-up was owed in the first place. casehub-life applies the same formal accountability structure to household coordination that casehub-aml applies to AML investigations: commitments that are tracked, deadlines that escalate, and a tamper-evident record for decisions that matter.

A contractor follow-up becomes a Qhorus commitment with a watchdog — if no ETA arrives by a specified time, an automated SMS fires via casehub-connectors. A health appointment becomes a WorkItem with a SLA and a named escalation target. A major financial decision requires a human RESPONSE before any action is taken, not as a soft preference but as a formal gate. OpenClaw provides the execution layer; casehub-life provides the accountability layer that makes those skills responsible rather than just capable.

The tutorial is seven layers demonstrating a concrete gap at each step — the clearest proof that formal accountability infrastructure generalises well beyond regulated enterprise domains.

View on GitHub ↗

Document review grounded in specific text, with multiple reviewer agents and a full audit trail

Document review with an LLM usually means pasting the whole thing and asking what's wrong with it. The response covers the document as a whole, isn't tied to any specific region, and leaves no record of what was looked at or what was returned. DraftHouse is different.

Any MCP client can open a document, show a before/after revision, and invoke reviewer agents with distinct personalities and areas of focus. Conversations are anchored to specific text selections. Each reviewer is independent. Each round of feedback is tied to the version it assessed. The full session is tracked via Qhorus channels — what was shown, who reviewed it, what came back.

DraftHouse is the lightest application in the ecosystem and a useful entry point — the Qhorus integration pattern it demonstrates applies to every other application in the stack.

View on GitHub ↗