Manifesto
The Anti-Hype Manifesto.
We start by finding out what your system needs.
A working demo leaves questions about data access, permissions and failure handling. We inspect one workflow and write down the evidence behind our recommendation.
That recommendation may be to fix the system, redesign it or stop the work. Implementation follows only after you approve the scope.
Your team should be able to inspect the reasoning and maintain the work we hand over.
Voice rules
How we describe and review our work.
01
State the conditions behind a claim.
Throughput, latency and accuracy depend on the workload and test conditions. We include those conditions when we publish a result.
02
Describe the limits.
A test result applies to what was tested. We distinguish a demo, an engineering example and a client result.
03
Label best-case results.
We label best-case numbers and explain how averages were measured.
04
Explain the tradeoffs.
When we describe faster delivery, we also describe the checks performed and the limitations that remain.
05
Link to evidence readers can inspect.
Repositories, architecture notes and test records let readers examine the work. Client details stay private until publication is approved.
What this commits us to
- · No "average X" velocity numbers. Best-case results carry the "up to" qualifier.
- · No "optimal defense", "guaranteed uptime", or any other absolutist framing on agent or security claims.
- · Every published case file links to an architecture diagram, a Loom, or an arXiv reference.
- · Every shipped engagement names the failure mode the buyer should expect.
- · When a pilot is not worth shipping, we say no out loud, on the record.