We build workflow software for teams whose decisions cannot wait for somebody to find the binder, reach a supervisor, or remember what the policy said. The answer arrives where the work is happening, in about thirty seconds.
Approach
Most operational knowledge lives in three places: a document nobody opens, the head of the one person who has done it before, and a phone call at an inconvenient hour. That is not a training problem. It is an interface problem, and it is solvable.
Most workflows ask for far more than the outcome depends on. We work out which facts actually change the answer, and cut everything that does not. Usually it is three or four questions.
Rules carry their own conditions, source and version. Policy changes are a content change, not a release — and when something becomes wrong, it can be corrected without shipping a new build.
On the device already in someone’s hand, answerable standing up, and honest when it does not know. Guidance that cannot be reached in the moment is guidance that does not exist.
Guidance that is right in general and wrong in the particular is worse than none at all. It reads as authoritative, and the person who notices one contradiction stops believing the rest of it. Everything we build is shaped by that.
First product
Device handling, workflows, and resources — built for teams handling mobile devices collected as evidence.
Someone is holding a device and needs to know what to do with it. DEVI asks a short set of questions, then shows the step that applies to that situation with the reasoning behind it. Where the process calls for a request to go to another unit, DEVI prepares it and opens it as a draft in the user’s own mail client. DEVI never sends it.
It asks for nothing the answer does not depend on. No case numbers, no forms, no data entry that exists only to fill a record.
Recommended step
Action required
Matched to what you described
Your answers, echoed back
Do this now
Why
Prepare request
Only what the outcome actually turns on. One screen, answerable standing up, in any order.
Matched against the organization’s own approved guidance and shown with the reasoning behind it — never generic advice that contradicts what was just described.
Assembled and addressed, then opened as a draft the user reads and sends themselves. Nothing leaves without a person deciding it should.
Engineering
Several of these cost us features. They are the reason the product can be put in front of a security team without a rewrite, and they apply to everything we build — not just this one.
Working data is held only as long as the task takes, and does not reach our servers. What the user produces goes to their own mail client and nowhere else.
The safest way to not mishandle sensitive data is to have nowhere to put it. Where a yes or no will do, that is all the software can express.
Procedural text is never compiled in. It carries a source and a version, because the world changes silently: a claim that was true when written can become false, and software that hard-codes it goes on saying it.
Operational guidance belongs to the organization deploying it. A build-time check fails the release if procedural language appears in unconfigured content.
Modern passkey authentication with biometric verification. No shared secret to intercept and no code to read out over a radio.
No diagnostic logging, and sensitive values are redacted by construction. No crash report can carry operational data off the device.
Contact
Downloading the app is not the same as getting access. There is no sign-up: an administrator creates each account deliberately, and only for an address at an approved domain. Registration is closed at two independent layers, so turning one off does not open the door.
Organizations interested in a pilot, and IT or security teams with questions about data handling, are welcome to get in touch directly.