What a first pilot involves
Six steps, in order. Most of the value is in the first three, and most of the difficulty is in the fourth.
Scope and duration are agreed in writing before work starts. The deliverable is the assessment, not an outcome that can be promised in advance.
The six steps
- 1
Bring a consequential workflow
One place where software acts and the consequence is real: money moves, configuration changes, a machine does something. Not the whole system. One workflow.
- 2
Identify the property that matters
Something it must never do, or an outcome it must be able to establish independently. Getting from a sentence everyone nods at to a sentence a machine can check is usually the hardest and most useful step.
- 3
Map what authorises the action
What decides this is allowed, when that decision is made, where it is recorded, and whether the record names the specific action or only its category.
- 4
Find what can independently observe the effect
What can see the result without asking the system that produced it. Frequently the honest answer is nothing yet, and identifying that is a real finding rather than a failed pilot.
- 5
Determine what can be checked mechanically
Given the authorisation and the observation, what a machine can decide without a human reading a log. A working check where one is possible, and a clear statement where one is not.
- 6
Define what evidence would be worth keeping
What record would let someone re-run the check months later and get the same answer, and what that record does not establish.
What comes back, and what does not
What comes back
- A written assessment. Whether the property can be expressed, observed and checked, with the three answered separately, because they fail separately.
- A working check where one is possible. Run against your workflow, with the command to run it again.
- What remains unknown. In the same weight as the rest. A pilot that ends in “this cannot be established with what exists today” is a successful pilot and is reported as one.
What a pilot is not
- Not a penetration test and not a vulnerability report.
- Not a product licence. There is no product to licence.
- Not a certification. Nothing here certifies anything to anyone.
- Not an audit of your team.
Scope and duration are agreed in writing before work starts. The deliverable is the assessment, not an outcome that can be promised in advance.
Bring a property
A property is one sentence about something that must always or never be true.
- No payment instruction executes unless a human approved that exact amount and recipient first.
- No configuration change reaches production equipment without a recorded authorisation naming that equipment.
- Every automated shutdown can be shown afterwards to have followed the rule it claims to have followed.
Omega Protocol assesses whether that requirement can be expressed precisely, observed from outside the system, and tested mechanically. Those three are separate questions and it is common for one of them to fail.
The limit of the offer
There is no claim here that arbitrary requirements can be met. The assessment is the deliverable, and a clear negative is a normal result.
Send it
There is no server behind this page
This site is static files. Nothing typed here is stored or transmitted by it, because there is nothing here that could receive it. The form assembles an email in your own client, and the whole message is shown before it is sent.