I work on the gap between what technology promises and what it changes in daily use. My questions concern judgment, attention and control: what should a system help someone do, and how will we know whether it helped?
These are the principles I use to guide IntuiTek¹’s research and engineering. The public work provides a way to examine how those principles hold up in practice.
On the unit
I start with the people who can recognize a problem, make a decision and observe the result.
An independent professional, an owner-operator or a small team may hold that knowledge directly. In a larger organization it may be spread across several roles. The important connection is between the person choosing a system and the person responsible for using it.
Before choosing technology, I want to understand the decisions involved, the constraints and the signs that would show an improvement. Keeping those questions close to the work makes the design easier to test.
On what AI is for
My aim is to support expertise and preserve the operator’s judgment.
AI can help retrieve information, organize material or propose an interpretation. Those functions need different checks. A useful design makes it clear which steps follow rules, which depend on model inference and which decisions remain with a person.
The test is whether the system helps with the actual task after the effort of checking, correcting and maintaining it is included. For consequential decisions, responsibility and review need to be explicit.
On sovereignty
People should understand and retain meaningful control over the systems they depend on.
I treat portability, access to data and clear ownership as design principles. That means documenting what can be exported, what can be moved, which services are required and what would happen if a provider became unavailable.
Some designs depend on hosted models, licensed software or external data. Those dependencies should be stated and evaluated, not hidden behind an unconditional promise of independence. The appropriate level of client control has to be established for each implementation.
On translation
By translation, I mean turning an operating problem into requirements a system can actually satisfy.
The starting point is the work itself: follow the documents, decisions and exceptions; ask where time or quality is lost; and identify what must remain under human control. A familiar workflow may contain constraints that a demonstration never encounters.
Technology selection follows that inquiry. The result might involve AI, ordinary software, a change in process or further research. Verification means checking the result in the conditions where it will be used.
On proof
A description should give readers a way to examine what supports it.
The Unified Cognitive Substrate preprint and released code provide public methods and experimental results. Defense Watch provides a working interface with visible data sources. Each supports a different kind of claim.
I distinguish those public artifacts from private work and internal experiments. A proposal describes an intended mechanism; a test reports what happened under stated conditions. A running system still needs dated records to establish uptime, recovery or a measured benefit.
On place
IntuiTek¹ is based in Poplar Bluff, Butler County, Missouri, in Southeast Missouri.
That is the setting for my work on systems people must understand, maintain and depend on. It keeps questions about time, operating knowledge and control close to the research.
The subject matter reaches beyond the region. Readers can follow the local background, the regional perspective and the public research.
On the operator
IntuiTek¹’s research and engineering are led by W. Kyle Million.
I want the reasoning behind a design to remain connected to its implementation and review. Working directly across those stages makes assumptions easier to revisit, but it also requires clear limits on scope and capacity.
Tools and delegated tasks can help carry out the work. They do not remove my responsibility to define authority, inspect results and make clear what remains unresolved.
On Aegis
Aegis is the AI-enabled operating laboratory I develop for work that spans tasks and interruptions. It combines memory, scheduling, tool use, delegation and recovery, with actions limited by the authority given to it.
The laboratory tests how saved context and action records can help a system resume work, recognize an uncertain outcome and avoid repeating an action blindly. Its model providers, software and external services remain dependencies of the implementation.
Uptime and recovery performance require dated operating records. Related questions appear in the Unified Cognitive Substrate research, the Emergent Judgment essays and the R4T-ACL proposal; their publication and validation status is explained in the research index.
On the work
I investigate the gap between what a system is intended to do and what can be observed when it runs.
The useful next step may be a clearer question, a test, a software change or a different process. I want that step to leave something another person can examine: a source, an implementation, a result or an account of what failed.
The work index brings those investigations together.
W. Kyle Million
IntuiTek¹ Poplar Bluff, Missouri