Bohmian verifiers

For work that can look right and still be wrong.

Choose the work you need to verify. See what each Bohmian specialist checks and an example of a failure it can catch.

Data & ML

Verify the methodology, not just the syntax.

Spearman

AVAILABLE

Spearman reviews Data + ML code for silent methodological failures that ordinary tests and general-purpose code review often miss — including leakage, invalid metrics, incorrect joins, flawed evaluation logic, and reproducibility risks.

What it evaluates

Temporal, label, and feature leakage
Evaluation integrity and metric validity
Feature logic, joins, grain, and data transformations
Reproducibility and non-determinism
Experiments, causal logic, forecasting, and performance claims

Where to use it

Python, SQL
Pull requests before merge
API and agent workflows
Wyrd requirement-aware verification

GitHubAPIWyrd

Real public verification examplebohmian.ai/demo

The work

A SQL training-table query executes and looks plausible, but joins multiple one-to-many sources before computing labels and metrics.

FROM orders
LEFT JOIN order_items ON ...
LEFT JOIN refunds ON ...
LEFT JOIN sessions ON ...

AVG(target) AS refund_rate
SUM(total_amount) AS gross_sales

Spearman finding

Duplicated, future-leaking rows make the training table methodologically invalid.

One logical order can become many rows. Revenue and refund metrics are then calculated over duplicated observations, while unconstrained customer activity can leak future information into features.

13 findings9 critical4 warning

Proposed remediation: restore one-row-per-order grain, pre-aggregate one-to-many sources, apply point-in-time predicates, then compute metrics and labels.

Use managed Data & ML verification.

Create a Bohmian account for Spearman, API credentials, usage, and supported integrations.

Create account →

Backend Systems

Catch failures that only appear when systems retry, race, or partially fail.

Mauchly

AVAILABLE

Mauchly examines state transitions, retry semantics, idempotency, concurrency, transactions, consistency, migrations, and failure handling — the logic that often survives unit tests but breaks in production.

What it evaluates

Idempotency and duplicate execution
Transaction boundaries and partial failure
Concurrency and state races
Retries, timeouts, and backoff behavior
Migrations and consistency assumptions

Where to use it

Python, SQL
Repository verification
API and agent workflows
Wyrd contracts for backend requirements

GitHubAPIWyrd

Illustrative exampleRetry / idempotency

The work

An order endpoint retries payment after a timeout. The payment succeeds remotely, but the first response is lost.

charge = gateway.charge(card, amount)
if timeout:
    return retry_order(order_id)

mark_paid(order_id)

Mauchly finding

A retry can charge the customer twice because payment has no stable idempotency key.

The local operation treats timeout as failure even though the remote side may have committed. Retrying performs another externally visible side effect.

Suggested remediation: derive a stable idempotency key from the order/payment attempt and persist the external payment state before allowing replay.

Use managed Backend Systems verification.

Enable Mauchly in a Bohmian account or call it through Wyrd.

Create account →

Application Security

Verify the authorization boundary your application actually enforces.

Driscoll

AVAILABLE

Driscoll focuses on application-layer exploitability: authorization, tenant isolation, injection paths, sensitive flows, and business-logic abuse — not generic vulnerability enumeration.

What it evaluates

Authorization and object-level access control
Tenant isolation
Injection and unsafe data flow
Sensitive actions and privilege transitions
Business-logic abuse and exploitability

Where to use it

Python, SQL
Security-sensitive service changes
API and agent workflows
Wyrd assurance requirements

GitHubAPIWyrd

Illustrative exampleTenant isolation

The work

An authenticated route fetches a report by ID and checks that the user is logged in, but never constrains the report to the user's tenant.

report = db.reports.get(report_id)
require_authenticated(user)
return report

Driscoll finding

Any authenticated user can request a report belonging to another tenant.

Authentication is present, but object authorization is missing. Knowing or guessing another report ID crosses the tenant boundary.

Suggested remediation: scope the lookup to the authenticated tenant or enforce a tenant ownership check before materializing the object.

Use managed Application Security verification.

Create a Bohmian account to enable Driscoll across supported surfaces.

Create account →

Optimization & OR

A solver can succeed while solving the wrong problem.

Blackett

AVAILABLE

Blackett verifies the semantics of optimization models: objectives, constraints, units, feasibility, and whether the mathematical formulation actually represents the operational problem.

What it evaluates

Objective functions and signs
Missing or inconsistent constraints
Units and dimensional consistency
Feasibility and boundary conditions
Real-world consistency of the formulation

Where to use it

Python, SQL
Optimization and scheduling code
Resource-allocation models
Wyrd requirements around model behavior

GitHubAPIWyrd

Illustrative exampleMissing constraint

The work

A warehouse allocation model minimizes shipping cost and satisfies customer demand, but never constrains outbound volume by warehouse capacity.

minimize sum(cost[w,c] * ship[w,c])

for c:
    sum(ship[w,c] for w) >= demand[c]

# capacity[w] never used

Blackett finding

The optimizer can assign unlimited volume to the cheapest warehouse.

The solution is mathematically feasible under the encoded model but operationally impossible. The missing capacity constraint changes the optimal allocation itself.

Suggested remediation: add per-warehouse throughput/capacity constraints with consistent units and validate utilization against the planning horizon.

Use managed Optimization & OR verification.

Create a Bohmian account to use Blackett across supported surfaces.

Create account →

Contracts & Legal

Find document failures before they become decision failures.

Hohfeld

PREVIEW · REQUEST ACCESS

Hohfeld verifies legal documents for contradictions, broken references, inconsistent definitions, explicit requirement failures, unsupported propositions, and material document logic — without inventing legal requirements you did not provide.

What it evaluates

Conflicting rights, obligations, dates, and thresholds
Definitions and cross-references
Explicit playbook or requirement conformance
Material ambiguity and document logic
Evidence support when supplied

Where to use it

DOCX web upload
Authenticated API
Wyrd requirement-aware verification

Web uploadAPIWyrd

Illustrative exampleContract consistency

The work

An agreement says invoices are due in 30 days in one section and 15 days in another, references a nonexistent section, and caps liability at three months despite an explicit 12-month requirement.

§2 Payment due: 30 days
§7 Payment due: 15 days
See §14.3 [missing]

Liability cap: 3 months fees
Requirement: >= 12 months fees

Hohfeld finding

The agreement contains conflicting payment obligations and fails the supplied liability-cap requirement.

Hohfeld anchors each finding to the relevant document text and separately assesses explicit requirements. The missing cross-reference is also identified without assuming external law.

Use managed Contracts & Legal verification.

Upload a DOCX or call Hohfeld through the API.

Create account →

Finance & Spreadsheets

Make sure the spreadsheet tells the same story its numbers claim to tell.

Newmarch

PREVIEW · REQUEST ACCESS

Newmarch provides specialist assurance for spreadsheet-based financial models: model mechanics, assumptions, scenario propagation, valuation logic, reconciliation, and narrative consistency.

What it evaluates

Financial statement relationships
Formula and model mechanics
Scenario propagation
Assumption consistency
Valuation and narrative consistency

Where to use it

Excel upload
API
Wyrd

Excel uploadAPIWyrd

Illustrative exampleScenario propagation

The work

A downside revenue scenario updates the income statement, but the cash-flow schedule still references the base-case working-capital assumptions.

Revenue_Downside = Revenue_Base * 0.85
EBITDA = Revenue_Downside - Costs

CashFlow!ΔNWC = BaseCase!ΔNWC
Valuation = CashFlow / WACC

Newmarch finding

The downside case understates liquidity impact because working capital does not propagate with the scenario.

The workbook recalculates without error, yet the scenario is internally inconsistent. Cash flow and valuation therefore do not reflect the same downside assumptions as the income statement.

Use managed Finance & Spreadsheets verification.

Create a Bohmian account to upload spreadsheets, call Newmarch through the API, or use Wyrd.

Create account →

First-party verifiers for Wyrd

Bohmian verifiers turn assurance contracts into evidence.

Wyrd defines what must be true. Bohmian verifiers can ingest those requirements directly, apply specialist judgment to the work, and return structured evidence showing where each condition was met — and where it was not.

01 · Wyrd assurance contract

Requirements in.

The contract expresses the conditions the work must satisfy without hard-coding the verifier that judges them.

invoice-analysis.ymlcontract v1

01REQ-017

Invoice totals must reconcile to approved line items.Evidence must identify the compared sources and any discrepancy.

02REQ-018

Partner ranking must not use future information.Evidence must assess temporal leakage in features and labels.

03REQ-019

Evaluation metric must match the declared business objective.Evidence must connect the metric definition to the stated objective.

02 · Bohmian verifier

Specialist judgment.

A Bohmian verifier receives the artifact plus the relevant Wyrd requirements and evaluates them with domain-specific reasoning.

SpearmanData & ML verifier
Wyrd-aware

artifactrequirementscontextevidence

03 · Wyrd evidence record

Evidence out.

The verifier returns evidence against the contract — including both satisfied and unsatisfied conditions.

Verification result2 of 3 satisfied

verifier

Bohmian · Spearman

REQ-017

satisfied

REQ-018

not satisfied

REQ-019

satisfied

provenance

artifact hash · contract v1 · verifier result

REQ-017 · satisfiedApproved line-item source and invoice output reconcile with no unexplained variance.

REQ-018 · not satisfiedA feature window includes observations that occur after the prediction timestamp.

Contract-aware.

Bohmian verifiers can evaluate explicit Wyrd requirements rather than only running a fixed, generic review.

Evidence-producing.

Results map back to the conditions in the contract, with findings and provenance Wyrd can preserve and reason over.

First-party, not exclusive.

Bohmian verifiers are purpose-built for Wyrd, while the same contract can also route to customer-owned or third-party verifiers.

Wyrd defines the assurance contract. Bohmian provides first-party specialist judgment inside that open system.

Managed assurance

Put specialist judgment to work.

Create a Bohmian account to access managed specialist verifiers, route work from Wyrd, and keep the evidence behind each assurance decision.

SPECIALIST VERIFIERSASSURANCE INTENSITYREQUIREMENTS NATIVE

Create Bohmian account