It works.
Normal conditions. Latency is flat, queues stay empty, every request is answered inside its budget.
p99 flat · queue depth 0–1 · errors 0%
Independent technology diagnostics
Find where your system breaks. Before production does.
We determine the operating limits, failure boundaries and technical constraints of complex systems — and prove them with evidence you can reproduce.
ConfidentialIndependentEvidence-based
You are reading Board, for founders, owners and investors. Turn to Bench, the reading for engineers.
The question
How far can your system go?
Most systems are tested while they work. We examine what happens when conditions stop being ideal.
One workflow under load · p99 latency against concurrent sessionsIllustrative
StableDegradedFailure
p99 budget 2.0 s
Failure boundary · 8 sessions
Concurrent sessions
StateStableLatency flat, queues empty. Every request answered inside the budget.
p99 latency590ms
Throughput10req/s
Errors0%
An illustrative examination of one agent workflow. Not a client result.
The question is not whether your system works. The question is where it stops working.
The problem
Working is not the same as scalable.
Every system has an operating range. Demos and happy-path tests only ever see the first part of it.
It degrades.
Concurrency, resource pressure and latency start to interact. The tail moves long before the average does.
p99 rising · pools saturating · retries appear
It fails.
The system crosses its operating boundary. Queues grow without bound, retries amplify load, and it does not recover on its own.
p99 unbounded · queue growing · errors climbing
The examination
We examine the system.
Not your AI, your roadmap or your team. The running system — measured along five dimensions that meet at one boundary.
Execution
How the system actually executes, path by path.
call paths · critical sectionsConcurrency
What changes under simultaneous demand.
sessions · contention · locksLatency
Where response time becomes unacceptable.
p50 · p99 · p99.9Resource pressure
Where compute, memory and queues become the limit.
CPU · memory · queues · poolsDeterminism
How reproducibly it behaves under equivalent conditions.
run-to-run variance · jitter
How an examination runs
Five steps. One boundary.
Select
One critical workflow, the one whose failure would cost the most.
Stress
Controlled operating conditions, raised one step at a time.
Observe
Actual behaviour, measured at every step. Nothing assumed.
Locate
The boundary identified, together with the mechanism behind it.
Prove
Reproducible evidence: the harness, the conditions, the data.
What you receive
You get a boundary.
A documented technical boundary: where the system’s behaviour changes, why, and under what conditions it happens again.
A generic benchmark scoreA consultant’s opinionPass or fail
DY PROOF
Failure Boundary Report
Executive finding
The workflow holds its 2.0 s p99 budget up to 8 concurrent sessions. Above 8, tool-call retries saturate a shared connection pool and latency grows without bound.
Normal operationDegradationFailure
- Operating condition
- Production configuration on staging hardware; one inference endpoint; tool calls through a shared HTTP pool of 8 connections.
- Observed boundary
- 8 concurrent sessions. At 9, p99 leaves the budget and does not return while load holds.
- Failure mechanism
- Retries share the pool with first attempts. At saturation, retries queue behind the requests they retry, and queue depth grows every second.
- Evidence
- 12 load steps × 5 runs. Latency histograms, pool-wait traces, queue depth per second. appendix A
- Reproduction conditions
- Harness, seeds and configuration delivered with the report; one command re-runs every step. appendix B
- Recommended action
- Give retries their own pool; cap retries at 2 per call with jitter; admit sessions above 8 only when the pool has headroom. Then re-examine.
- Confidence
- High — the boundary reproduced in 5 of 5 runs, within one session.
Confidential. Prepared for the client only.Specimen: illustrative content, not a client result.
Every report follows this structure: finding, operating range, boundary, mechanism, evidence, reproduction, action and confidence.
Engagements
Start with one workflow.
Each engagement answers one question, and leads to the next only if you need it. The first boundary tells you where to look.
- Whereone workflow breaks
- How farthe whole system can go
- Whyit breaks, and whether the fix holds
72 hoursStart here
Failure Boundary
$950
Where does one critical workflow stop behaving acceptably?
- One critical workflow
- One load axis, raised step by step
- The boundary and its mechanism
- Written result. No meetings.
- The fee is credited in full toward the Boundary Map if you continue within 30 days.
7 working days
System Boundary Map
$3,900
How far can the whole system go, and what gives way first?
- Up to five critical workflows
- All five dimensions, measured
- The operating envelope, workflow by workflow
- One re-examination after your fix
2–3 weeks
Runtime Diagnostics
from$9,500
Why does it break, and does the fix really move the boundary?
- Scheduling, jitter and determinism
- Mechanisms traced to their cause in code
- Every fix verified by re-examination
- The harness is yours, to run in your CI
Private · for investors and acquirers
Pre-investment examination
Runtime evidence for a deal: the target’s system examined under load before capital depends on it. Runs alongside DY Research due diligence — one scope, one report — or on its own.
Scoped with the dealRequest an examination
Scope and price agreed in writingNothing invoiced until the scope is agreedYour system and results stay privateBank transfer or DOGE · how to pay
DY PROOF or DY Research?
Prove · DY PROOF
Where does the running system stop working?
Produces new evidence: the system examined under controlled load until its boundary is found and reproduced.
Ends in a documented boundaryVerify · DY Research
Is what is claimed true?
Reads the evidence that exists: the code, the tests and the proofs behind a technology’s claims.
Ends in a written verdict · dyresearch.github.io ↗Different questions, different prices, one standard of evidence. For a deal, the two run as one engagement.
For investors
Before you finance scale.
A technical system can look impressive while carrying an undiscovered operating boundary.
DY PROOF provides an independent technical examination before capital, deployment or acquisition depends on the system.
Alongside DY Research due diligence, or on its own. The findings are technical; the investment decision stays yours.
Why DY PROOF
Nothing to sell you but the finding.
Independent
No incentive to confirm the conclusion you were hoping for.
Evidence
Every finding is tied to behaviour that was observed and recorded.
Reproducible
Conditions and method are documented, so any result can be re-run.
Confidential
Your system, your data and your results stay private.
Technical
Engineering findings in engineering terms. No management theatre.
Not a certification.
No examination issues or implies qualification under any safety or compliance standard.
Not investment advice.
The findings are technical. What to do with them is your decision.
Not a warranty.
You receive evidence and reasoning, set out so that they can be checked.
The DY engineering ecosystem
One house. Four layers.
From the infrastructure that is built to the diagnostics that prove how systems behave. Each layer works to the same rule: nothing is claimed that cannot be checked.
L4 DiagnosticsDY PROOFFailure-boundary diagnostics: where a running system breaks, located and reproduced.You are here
L3 VerificationDY ResearchDue diligence and worst-case timing: every claim traced to its evidence.dyresearch.github.io ↗
L2 IntelligenceThe RadarA living map of open neurotech, scored from public evidence.Radar ↗
L1 InfrastructureAxonOSThe deterministic real-time kernel for brain–computer interfaces. Open.axonos.org ↗
Independence
AxonOS is open infrastructure, built and funded by the house and bound for independent foundation governance. Belonging to the ecosystem never shapes a finding. If a system under examination competes with AxonOS or builds on it, you are told at scoping — before you commit to anything.
Think your system is ready?
Let’s DY it.
Send one workflow. Get its boundary back in writing — before production finds it for you.