Related Pages

Related topics: Verdict Bus, Graders & Self-Healing CI, Brain, Scope Lattice & Shared Verified Memory, Fleet, Tool-smith, Surfaces & Operations

Overview & the Multi-Organ Architecture

Purpose and Thesis

Verel is an agent framework positioned as a verification substrate — a layer any agent can call (locally or over MCP) so that work is treated as a *hypothesis* until a grader returns a verdict. The single load-bearing idea, lifted from the project README, is that an agent's output is never trusted by default: it must be reduced to a unified pass / warn / fail before it is allowed to compound into long-term memory.

*"an agent's output is a hypothesis until a grader returns a verdict. Verel unifies every check — tests, types, lint, vision, perf, security — into one pass / warn / fail, and only verified work is allowed to compound into memory."*

Source: src/verel/README.md:1-15

This shape was hardened in v0.30.0 (the verification substrate release) and extended in v0.31.0 (the shared verified brain) so that any agent over MCP can recall, remember, and verify against the same trust substrate. Source: v0.31.0 release notes.

The Organ Map

The package is divided into specialized modules ("organs") that each speak the verdict contract. The canonical list, taken from the module guide, is:

Source: src/verel/README.md:17-39

Note on terminology: the module README labels this table *"The six organs at a glance"*, but the table itself lists seven rows. The page preserves the source's actual surface so newcomers can map tasks to packages.

The Verdict Bus — the Central Contract

Every other organ — eyes, brain, fleet, tool-smith, CI, registry — produces a Report and asks gate() to reduce a set of reports to one verdict. The models that flow on that bus live in verel.verdict.models:

• Report — one grader's evaluation, carrying a Verdict (PASS/WARN/FAIL), a GraderKind, a summary, and a list of Issues.
• Issue — typed finding with kind, severity, source (the originating grader), an optional locator, and a NIRVANA-computed fingerprint that the bus assigns after construction.
• Gate — the reducer, which collapses a list of Reports under a few non-negotiable rules.

Source: src/verel/verdict/models.py:1-60

The bus is intentionally thin: it does not know about perception, memory, or CI — it only knows how to *combine verdicts*. This is what lets a CI stage and a vision saccade and a remote brain attestation all land on the same Verdict and be reasoned about uniformly.

The Memory / Brain Layer

The brain is the trust substrate. Its public surface is re-exported from verel.memory.__init__, including the four-tier trust model (MemoryRecord, Trust, MemoryView, LocalMemory), the embedding shims (Embedder, HashEmbedder, OpenAIEmbedder), the consolidation and revision passes, the failure ledger, the held-out promotion gate, and the HA surface (ReplicatedMemory, AntiEntropy). Source: src/verel/memory/__init__.py:1-30

Three behaviors distinguish verel's brain from a plain vector store:

1. Interference rule. A write with the same (subject, predicate, scope) key supersedes the prior record rather than duplicating it; identical text *corroborates* (raises confidence and support_count, resets retrieval_strength). Source: src/verel/memory/local.py:1-40
2. Two-layer consolidation. Failures are clustered (semantically when an embedder is present, otherwise by the coarse detail['kind']) and lifted into structured DESIGN_RULEs, then clustered again into SCHEMA principles. Both layers write trust=candidate — trust is never auto-verified. Source: src/verel/memory/consolidate.py:1-30
3. Contradiction-driven revision. When a rule accumulates counterexamples, the rule is *weakened*, *split* into a narrowed general rule plus an exception, or *rejected* — never auto-verified. Source: src/verel/memory/revise.py:1-20

These three rules are the substrate's way of enforcing the "trust does not travel" property called out in v0.30.0. The release-notes progression v0.31.0 → v0.32.0 → v0.34.0 layers remote-brain access, ed25519 authenticated principals, and fact-bound cross-principal attestation on top of the same in-process trust model.

The Agent, Senses, CI, and Tool-Smith Organs

• Agents (verel.agents) — currently the coding agent and a FixHook factory. Source: src/verel/agents/__init__.py:1-10
• Senses (verel.senses) — SightResult carries one Report per source-grader (dom/ocr/cv/vision) plus a combined Percept envelope, mapped through a closed 4-value source-to-grader table. Source: src/verel/senses/sight.py:1-30
• CI / grading (verel.ci) — re-exports run_stage, self_heal, HealResult, the rollback policy/decision/outcome trio, and the pre-commit installer. Source: src/verel/ci/__init__.py:1-12 The current LANGS table grades Python (pytest+ruff+mypy), JS (jstest+eslint+tsc), and Go (gotest+govet); Rust is a tracked gap (Issue #1). Source: src/verel/ci/graders.py:1-10
• Tool-smith (verel.toolsmith) — agents that build and sandbox their own tools, with a seccomp-bpf denylist layered on top of a bwrap container when the container extra is installed. Source: src/verel/toolsmith/seccomp.py:1-25
• Registry (verel.registry) — PublicRegistry is a content-addressed store of signed SkillArtifacts; the content hash is the namespace and a foreign-origin overwrite is refused. Source: src/verel/registry/store.py:1-25

How the Organs Compose

flowchart LR
    A[Agent / FixHook<br/>verel.agents] --> R[Reports]
    S[Senses / AgentVision<br/>verel.senses] --> R
    C[CI Graders<br/>verel.ci] --> R
    T[Tool-smith<br/>verel.toolsmith] --> R
    R --> G[Verdict Bus<br/>verel.verdict.gate]
    G -->|PASS / WARN / FAIL| M[Memory / Brain<br/>verel.memory]
    M -->|verified facts & skills| Reg[Skill Registry<br/>verel.registry]
    M -. recall / remember .-> MCP[(MCP substrate<br/>v0.35.0)]
    Reg -. signed skills .-> MCP
    G -. runreceipt .-> MCP

Reading the diagram bottom-up: every organ emits Reports; the bus gates them; only gated results compound into the brain; the brain, the registry, and the run-receipt surface are all reachable over MCP since v0.30.0, and the HTTP transports are now TLS-hardened since v0.36.0.

Common Failure Modes and Gaps

• Mis-attributed feedback in the brain. Without the corroboration/contradiction accounting in src/verel/memory/local.py, a single bad actor can poison a shared brain — the reason AuthorTrust and import_belief re-verification exist on top of the local view.
• Auto-verification creep. A bug elsewhere could shortcut trust=candidate to verified; the design rule in src/verel/memory/consolidate.py:1-30 and src/verel/memory/revise.py:1-20 is that revision only *lowers* trust or *narrows* scope.
• Undetected missing extras. Issue #2 notes that verel doctor does not yet show which optional extras (e.g., verel[sight], verel[container]) are installed or which provider keys are present — newcomers may install verel and assume a sense is wired when it is not.
• Monorepo CI gaps. Issue #4 requests a recipe for *gating a monorepo with per-package stages*; the LANGS table in src/verel/ci/graders.py:1-10 today keys a stage to a single language, so per-package gating is still caller-side composition.
• Parser coverage. Issue #3 asks for broader grader-parser fixtures in tests/test_ci_senses.py; the parsers in src/verel/ci/graders.py are pure functions over (stdout, stderr), so the gap is purely a test-data gap, not a design gap.

See Also

• Developer guide / cookbook — task-oriented recipes referenced by the monorepo gap (Issue #4).
• v0.36.0 release notes — TLS for routable brain/lease/registry binds — the transport layer that hardens the brain, lease, and registry services.
• v0.34.0 — cross-principal verified tier (fact-bound attestation) — the most recent addition to the trust substrate.
• Issue #1 — add Rust toolchain graders to verel.ci.graders.
• Issue #2 — extend verel doctor to report installed extras and key presence.

Related Pages

Related topics: Overview & the Five-Organ Architecture, Fleet, Tool-smith, Surfaces & Operations

Verdict Bus, Graders & Self-Healing CI

Verel treats an agent's output as a *hypothesis* until a grader returns a verdict. The verdict bus is the single contract every sense (vision, tests, lint, types, security, perf) speaks, and the self-healing CI organ reuses the same contract to gate commits, merge requests, inner dev loops, and post-merge smoke runs. This page explains how the contract works, which graders ship, and how failures are classified, recorded, and replayed.

The Verdict Bus — One Contract, One Reducer

The bus is defined under src/verel/verdict/. Every grader — AgentVision, pytest, ruff, the LLM judge, a code-review skill — produces a Report carrying a Verdict (pass/warn/fail), a GraderKind, and a list of Issue objects. The reducer is gate(), exposed in src/verel/verdict/__init__.py.

gate() enforces three non-negotiable rules, all parameterised by named constants in src/verel/verdict/constants.py:

from verel.verdict import Report, Issue, IssueKind, Severity, GraderKind, Verdict, gate, assign
r = assign(Report(verdict=Verdict.FAIL, summary="2 type errors", grader=GraderKind.TYPECHECK,
                  issues=[Issue(kind=IssueKind.OTHER, severity=Severity.ERROR,
                                source=GraderKind.TYPECHECK, message="bad return",
                                locator="app.py:42")]))
print(gate([r], required={GraderKind.TYPECHECK}).verdict)   # Verdict.FAIL

assign() lives in src/verel/verdict/fingerprint.py; it scrubs volatile fields (line numbers, addresses, floats) so the same underlying issue produces the same fingerprint across runs. The model surface (Report, Issue, RunReceipt, GateResult, and the enums Verdict / Severity / GraderKind / IssueKind) is defined in src/verel/verdict/models.py. A gate() that requires a grader also demands a signed RunReceipt — the attestation rule, issued via sign_receipt() and checked by verify_signature() in src/verel/verdict/gate.py. Without a receipt, a required grader fails closed.

Code Graders — Deterministic, Pure, Testable

src/verel/ci/graders.py defines a GraderSpec per toolchain: a frozen command, a parser, and a LangToolchain binding. Parsers are pure functions over (stdout, stderr), so the corpus in tests/test_ci_senses.py drives them offline. The command runner is injectable (subprocess_runner by default) for the same reason.

The full list of language tags and the LANGS mapping is exported from src/verel/ci/__init__.py. Each parser emits Issue records with stable source=GraderKind.* so the fingerprint reducer does not confuse a mypy error with a ruff warning, and run_grader() signs a RunReceipt keyed on suite_sha() plus a bound_input_digest of the changed files — the same digest that the gate receipts over.

Community note: the project tracks a feature request to add a Rust toolchain (cargo test + clippy) following the existing GraderSpec pattern (issue #1), and to widen the parser corpus with real tool output (issue #3). Both are mechanical extensions of the current grader table.

Self-Healing CI — Stages, Medic, and Failure Memory

src/verel/ci/pipeline.py exposes four named stages and a single entry point, run_stage(stage, ...). Each Stage pairs a list of GraderSpecs with a required set; run_stage runs every grader, gates the resulting Reports, and consults a FailureLedger for regressions. A StageResult carries the verdict, the underlying GateResult, the raw reports, and any regressions.

flowchart LR
  A[Change set] --> B[run_stage]
  B --> C[run_grader ×N]
  C --> D[Verdict bus: gate()]
  D --> E{Required & receipted?}
  E -- no --> F[FAIL: hollow gate]
  E -- yes --> G[FailureLedger regression?]
  G -- yes --> H[FAIL: known regression]
  G -- no --> I[ci-medic classify]
  I --> J[(RETRY · REGEN · QUARANTINE · FIX)]
  J --> K[Verdict: PASS / WARN / FAIL]

The ci-medic (src/verel/ci/medic.py) is deterministic, not LLM-driven. It pattern-matches grader output to one of four Actions:

A diagnostic Diagnosis may be enriched by an LLM later, but the classification itself is regex-driven so the medic cannot be gamed. Destructive follow-ups (FIX_BRANCH, lockfile regeneration) are additionally filtered through the RollbackPolicy engine (rollback.py) and the canary_rollback helper exported from the same package, so a medic misclassification cannot push destructive changes on advisory evidence.

A self_heal() loop is exposed from src/verel/ci/__init__.py (along with HealResult / HealRound); it iterates the medic's recommendations, re-runs the stage, and stops when a non-RETRY action succeeds or the round budget is exhausted. Pre-commit hook installation lives in hooks.py (install_precommit, is_installed).

Failure Memory — Anti-Regression, Consolidation, Revision

The same Report stream that gates a commit is also written into the failure ledger, defined in src/verel/memory/view.py as a FAILURE-kind MemoryRecord. The pipeline consults this ledger via regression_report() in failure_ledger.py, so a change that reintroduces a previously-fixed signature is gated FAIL from memory alone — no need to re-run the failing test to notice the regression.

Records are persisted by src/verel/memory/local.py: a write with the same (subject, predicate, scope) supersedes the prior record, accumulating support_count and bumping epistemic_confidence; conflicting writes drop confidence via contradict(). Three higher-level modules then turn failures into durable, falsifiable memory:

• src/verel/memory/consolidate.py clusters failures (semantically if an embedder is available, by detail['kind'] otherwise), induces a structured DesignRule per cluster, and clusters rules into a 2nd-order SCHEMA. All writes are trust=candidate — verification is never granted by consolidation alone.
• src/verel/memory/revise.py handles the contraction half: a counterexample in a rule's domain narrows the rule (supersedes the original via the same subj_pred_key) and may split it into a narrowed general rule + a specific exception, both candidate. Confidence collapse leads to rejected.
• src/verel/memory/promotion.py gates the climb from candidate to verified behind a signed, human-owned HeldOutCorpus; the rule must reach PROMOTE_F1 = 0.8 on canary-marked cases to be promoted.

The bus surface that ties this together — verdict.fact_commitment, attest_fact, verify_fact_attestation — was hardened across v0.32.0 – v0.36.0 (see the release notes) so peer beliefs and shared-brain reads carry the same attestation contract as a local grader.

Common Failure Modes

• Hollow gate — a stage declares a required grader but the report lacks a RunReceipt. gate() fails closed. Fix: ensure run_grader ran (not just a parser on cached output) and that sign_receipt produced a signature.
• Advisory gating ignored — code treats an LLM_JUDGE or VISION CRITICAL as blocking. The advisory ceiling in constants.py will clamp it to WARN; the bug is in the consumer.
• Flaky test thrash — a QUARANTINE_FLAKY action is the correct response; do not loop FIX_BRANCH on a known flaky signature, and do not delete the test.
• Monorepo scope — run_stage takes a diff_files set, so a stage can be filtered to one package. Community recipe for per-package gating in monorepos is tracked in issue #4.

See Also

• Developer guide — usage cookbook
• src/verel/memory/view.py — MemoryRecord, Trust, MemoryKind
• v0.30.0 release — the verification substrate
• v0.36.0 release — TLS for routable brain/lease/registry binds

Related Pages

Related topics: Overview & the Five-Organ Architecture, Fleet, Tool-smith, Surfaces & Operations

Brain, Scope Lattice & Shared Verified Memory

Overview & Role in the Substrate

Verel's brain is the trust layer that turns per-episode perceptions into durable, recallable knowledge for agents. It sits behind the same MemoryView Protocol regardless of backend (local SQLite, hosted HTTP MemoryServer, replicated cluster, or a mem0/Ollama adapter), so an agent never has to change code to swap substrates. The thesis, taken from the module guide (src/verel/README.md), is that an agent's output is a *hypothesis* until a grader returns a verdict; the brain's job is to keep that hypothesis from polluting future runs. The two orthogonal quantities the brain tracks are epistemic_confidence (how strongly the substrate believes the claim) and retrieval_strength (how reachable the claim is right now), kept separate on purpose so belief and reachability can be tuned independently (src/verel/memory/view.py).

flowchart LR
    A[Agent / MCP tool] -->|verel_recall / verel_remember| B[MemoryView]
    B --> C[Scope Lattice<br/>self &lt; team &lt; org &lt; global]
    C --> D[LocalMemory<br/>SQLite]
    C --> E[MemoryServer<br/>HTTP/TLS]
    C --> F[ReplicatedMemory<br/>HA cluster]
    B --> G[Trust gate:<br/>candidate → verified]
    G --> H[Consolidate / Revise]
    H -->|DesignRule, Schema| D
    H -->|counterexample| I[Reject / Narrow]

MemoryRecord, Trust Tiers & the Interference Rule

Every belief is a MemoryRecord with a content-addressed identity: the id is derived from the normalized (subject, predicate, scope) triple via make_key / make_id (src/verel/memory/view.py). The kind is one of FACT, DESIGN_RULE, SCHEMA, FAILURE, or SKILL — the same key is used regardless of kind, so a FACT and a SKILL with the same (subject, predicate, scope) share an id, which is why src/verel/memory/principal.py keeps the five reserved predicates/scopes server-side and refuses a client write that collides with them.

Trust progresses through explicit tiers rather than a free-floating float (src/verel/memory/view.py):

The interference rule in LocalMemory.write is what keeps the store honest: if an incoming MemoryRecord collides on the subj_pred_key, the existing record is *superseded* (same text bumps support_count and confidence by 0.1, resets retrieval_strength); conflicting text is still kept but contradict-marked so the rule can collapse later (src/verel/memory/local.py).

Scope Lattice & Recall Resolution

Recalls are scoped. The lattice resolves DOWN — a read at self sees self < team < org < global, so an agent never gets a team claim when it asked for self, but team can see what its members learned. Scope strings are typed: repo:<name>, global, component:<x>, and the reserved meta:authors ledger used by AuthorTrust (src/verel/memory/share.py). The MCP surface verel_recall(query, scope, kind, k) introduced in v0.31.0 rides this lattice directly; with VEREL_BRAIN_URL set (v0.35.0) the same call reaches the remote MemoryServer, and v0.36.0 hardens the transport with TLS so a non-loopback bind fails closed (releases: v0.31.0, v0.35.0, v0.36.0).

A recall that returns a peer-authored belief is *not* trusted on the say-so of the peer — the importer re-verifies through a Verifier callback before confidence is updated, and the outcome is logged into AuthorTrust with a Laplace-smoothed prior. This is the principle the module guide calls "trust does not travel" (src/verel/README.md).

Consolidation, Revision & Schema Induction

Consolidation is the *growth* half of memory; revision is the *contraction* half. Both are offline-batch and use an injectable ChatFn so they're testable without network (src/verel/memory/consolidate.py, src/verel/memory/revise.py).

• Cluster recurring failures — semantically when an embedder is wired in, otherwise by the coarse detail['kind'] label.
• Induce a structured DESIGN_RULE with {condition, action, applies_to} slots, written as trust=candidate and epistemic_confidence=0.5.
• Induce a SCHEMA (order-2) by clustering rules; induce_hierarchy keeps walking up to max_order=4. Height never confers trust — every node still has to earn it.

When a new failure lands in a rule's domain, revise_with_counterexample (1) records the counterexample (no corroboration), (2) contradicts the rule (confidence drops by contradiction_delta=0.2), and (3) once split_after=2 counterexamples accumulate, splits the over-broad rule into a narrowed rule (which *supersedes* the original via the interference key) plus an exception rule — both candidate and both re-earning trust the normal way. If confidence collapses below the reject floor the rule is REJECTED. Revision only ever lowers trust or narrows scope, mirroring the same direction the GraderKind bus enforces for CI verdicts (src/verel/ci/graders.py).

See Also

• Module guide: src/verel/README.md — six organs at a glance and the gate / verdict contract
• v0.36.0 release notes — TLS for routable brain/lease/registry binds
• v0.35.0 release notes — MCP recall/remember over a remote authenticated brain
• v0.34.0 release notes — cross-principal verified tier (fact-bound attestation)
• v0.32.0 release notes — the authenticated multi-principal brain
• v0.31.0 release notes — the shared verified brain

Related Pages

Related topics: Overview & the Five-Organ Architecture, Verdict Bus, Graders & Self-Healing CI, Brain, Scope Lattice & Shared Verified Memory

Fleet, Tool-smith, Surfaces & Operations

Verel's "Fleet" and "Tool-smith" organs operationalize the rest of the substrate: the fleet is *agents managing agents*, and the tool-smith is *agents building and certifying their own tools*. Together with the operator-facing surfaces — the verel CLI, the verel-ci git-hook CLI, and the verel-mcp server — they close the loop from a grader verdict to a multi-tenant, sandboxed action that another party can verify.

Fleet — agents managing agents

The fleet module exports a v1-cut control plane: roles, retries, heartbeats, a single-writer scheduler over a Task DAG, manager fan-out, and a worker adapter that gates every node through the verdict bus (Source: src/verel/fleet/__init__.py:1-7).

The DAG lives in task.py and exposes Task, TaskState, Role, Barrier, BarrierKind, BudgetLease, and RetryPolicy. A scheduler in scheduler.py walks the DAG, and workers in worker.py wrap ultracode_worker / worktree_ultracode_worker so every node still passes through gate() before being marked done.

Coordination primitives are kept small but real:

• Leases — lease.py ships InMemoryLeaseStore and SqliteLeaseStore, with Lease, LeaseStore, and a FencingError for split-brain handling.
• Worktrees — worktree.py defines Worktree, WorktreeManager, and LeaseHeld, the isolation boundary used when many workers must edit the same repo concurrently.
• Manager fan-out — manager.py re-exports plan_over_artifacts, to_tasks, validate_fanout, clamp, plus the FanOut / Subtask models; the LLM-driven variant lives in llm_manager.py (decide_fanout).
• Multi-repo & sagas — multirepo.py plans cross-repo graphs (plan_multi_repo, repo_of, CrossDep); saga.py runs compensating workflows (run_saga, git_revert_head, SagaResult).
• Remote control plane — control_plane.py hosts ControlPlaneServer + RemoteLeaseStore so a fleet on different machines shares one lease authority.
• Git fencing — fence_sink.py wires validate_push, push_options, and write_pre_receive_hook for pre-receive enforcement.

The README explicitly scopes what is *not* in v1: "Worker fencing + git fencing sink are v3" (Source: src/verel/fleet/__init__.py:5-7), so treat remote worker fencing as a roadmap item, not a current control.

Tool-smith — agents building their own tools

The tool-smith organ implements the detect → scaffold → test → register → reuse lifecycle. Tools live as SKILL records in procedural memory behind the same MemoryView, gated by the same attested eval discipline as facts/skills — verified-and-auto for read-only/idempotent tools, human-review-gated for destructive ones (Source: src/verel/toolsmith/__init__.py:1-7).

Core pieces:

The README is explicit that "the in-process tool guard is a guardrail, not a sandbox — real isolation is the bwrap container runner (isolation='container'): no network, read-only system-only fs, ephemeral tmp, cleared env, and a seccomp-bpf syscall filter (verel[container])" (Source: README.md:42-50). Three profiles, weakest→strongest: denylist (default), allowlist, and capability (Source: src/verel/toolsmith/__init__.py:23-32).

The Coder agent in agents/coder.py (LLMCoder, make_fix_hook) bridges the verdict bus to file rewriting — make_fix_hook returns an async FixHook that ultracode_loop calls when a gate fails, so the same org produces a candidate patch that is immediately re-gated.

Surfaces — how operators reach the substrate

Three top-level surfaces are documented in the package README (Source: src/verel/README.md:23-30):

• cli.py → verel {doctor, loop, fleet, heal, ci} — the operator's day-to-day surface. Community issue #2 flags that doctor should additionally report installed extras and provider-key presence, which is a current gap.
• ci/__main__.py → verel-ci {check, precommit, install} — the git-hook / pre-commit surface; the LangToolchain map currently covers python, js, and go (Source: src/verel/ci/graders.py), with Rust requested in issue #1 and broader real-sample coverage in #3.
• mcp_server.py → verel-mcp — exposes the four hero verbs (gate, sight, recall/remember, verify) to any MCP-capable agent.

Operations, security posture, and known gaps

TLS for non-loopback binds is the headline of v0.36.0: MemoryServer, ControlPlaneServer, and RegistryServer accept certfile=/keyfile=/ssl_context=, loopback stays zero-config. Bind hardening fails closed when non-loopback is requested without cert material.

Operationally, three community-acknowledged gaps remain on these surfaces:

1. Monorepo gating recipe — verel-ci is repo-scoped; issue #4 asks for a docs/usage.md recipe and an examples/demo_monorepo_ci.py running separate inner loops per package.
2. Rust graders — issue #1 wants parse_cargo_test / parse_clippy next to the Python/JS/Go parsers.
3. Doctor completeness — issue #2 wants a small table of optional extras and present keys.

Until those land, the operational rule of thumb is: keep the verdict bus as the single entry point, keep destructive tools behind the allowlist or capability seccomp profile, and route any non-loopback fleet/brain/registry bind through TLS.

See Also

• Verdict Bus & Eyes (sight, memory, registry)
• Memory Substrate — local, shared, revision, and librarian
• Skill Registry — artifacts, transfer, and H2 measurement
• Verel Security Model — sandbox vs. container, seccomp profiles

Doramagic Pitfall Log

Found 25 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification.

1. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: verel doctor: report installed extras and key presence
• User impact: Developers may expose sensitive permissions or credentials: verel doctor: report installed extras and key presence
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: verel doctor: report installed extras and key presence. Context: Observed when using docker
• Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/2

2. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Add a Rust toolchain (cargo test + clippy) to the CI graders
• User impact: Developers may fail before the first successful local run: Add a Rust toolchain (cargo test + clippy) to the CI graders
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Add a Rust toolchain (cargo test + clippy) to the CI graders. Context: Observed when using python
• Evidence: failure_mode_cluster:github_issue | https://github.com/amitpatole/verel/issues/1

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.28.0 — quorum reads: a point read survives the leader being down
• User impact: Upgrade or migration may change expected behavior: v0.28.0 — quorum reads: a point read survives the leader being down
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.28.0 — quorum reads: a point read survives the leader being down. Context: Observed when using node, python
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.28.0

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.29.0 — security hardening: full attack-surface audit + red-team
• User impact: Upgrade or migration may change expected behavior: v0.29.0 — security hardening: full attack-surface audit + red-team
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.29.0 — security hardening: full attack-surface audit + red-team. Context: Observed when using python, docker
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.0

5. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.29.1 — security: 3-round adversarial red-team
• User impact: Upgrade or migration may change expected behavior: v0.29.1 — security: 3-round adversarial red-team
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.29.1 — security: 3-round adversarial red-team. Context: Observed when using python, docker
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.1

6. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.29.2 — CI fix for the v0.29.1 security release
• User impact: Upgrade or migration may change expected behavior: v0.29.2 — CI fix for the v0.29.1 security release
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.29.2 — CI fix for the v0.29.1 security release. Context: Observed when using python, docker
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.29.2

7. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.30.0 — the verification substrate
• User impact: Upgrade or migration may change expected behavior: v0.30.0 — the verification substrate
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.30.0 — the verification substrate. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.30.0

8. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.31.0 — the shared verified brain
• User impact: Upgrade or migration may change expected behavior: v0.31.0 — the shared verified brain
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.31.0 — the shared verified brain. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.31.0

9. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.32.0 — the authenticated multi-principal brain
• User impact: Upgrade or migration may change expected behavior: v0.32.0 — the authenticated multi-principal brain
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.32.0 — the authenticated multi-principal brain. Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.32.0

10. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.34.0 — cross-principal verified tier (fact-bound attestation)
• User impact: Upgrade or migration may change expected behavior: v0.34.0 — cross-principal verified tier (fact-bound attestation)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.34.0 — cross-principal verified tier (fact-bound attestation). Context: Observed when using python
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.34.0

11. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.35.0 — MCP recall/remember over a remote authenticated brain
• User impact: Upgrade or migration may change expected behavior: v0.35.0 — MCP recall/remember over a remote authenticated brain
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.35.0 — MCP recall/remember over a remote authenticated brain. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | https://github.com/amitpatole/verel/releases/tag/v0.35.0

12. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/amitpatole/verel/issues/1

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using verel with real data or production workflows.

• Docs: add a 'gate a monorepo with per-package stages' recipe - github / github_issue
• Broaden grader-parser test coverage with more real tool-output samples - github / github_issue
• verel doctor: report installed extras and key presence - github / github_issue
• Add a Rust toolchain (cargo test + clippy) to the CI graders - github / github_issue
• v0.37.0 — mTLS, certificate pinning, per-IP fairness - github / github_release
• v0.36.0 — TLS for routable brain/lease/registry binds - github / github_release
• v0.35.0 — MCP recall/remember over a remote authenticated brain - github / github_release
• v0.34.0 — cross-principal verified tier (fact-bound attestation) - github / github_release
• v0.32.0 — the authenticated multi-principal brain - github / github_release
• v0.31.0 — the shared verified brain - github / github_release
• v0.30.0 — the verification substrate - github / github_release
• v0.29.2 — CI fix for the v0.29.1 security release - github / github_release