Research & Technical Publications
Long-form technical papers and engineering notes on system architecture, adversarial verification, controlled evolution, privacy, sovereignty, ambient intelligence and high-consequence AI. Public editions explain principles and evidence while deliberately withholding implementation details that would reproduce proprietary work.
We publish enough to explain the thesis, architecture, evidence, limits and engineering consequences. We do not publish internal prompts, orchestration contracts, operational thresholds, security configuration, deployment playbooks or other details that would materially reproduce proprietary implementation.
11 technical papers · 23 engineering notes · architecture, evidence, sovereignty, controlled evolution and real-world systems
Long-form positions with architecture, limits and evidence.
These are public technical editions: deliberately detailed on principles and consequences, deliberately incomplete on reproducible proprietary implementation.
If a System Depends on its Provider, It Is Not Architecture
This paper argues that a system designed for critical operations that depends on a single model or infrastructure provider has a fragile, not strategic, architecture. It analyzes how provider dependence introduces technical, economic, and governance-related points of failure that compromise operational continuity. A conceptual architecture is developed based on principles of technological sovereignty, replaceable components via an abstraction layer, portability of data and artifacts, and human authority. Through a hypothetical case study, the outcomes of a dependent implementation are contrasted with those of a sovereign architectural design in the face of an adverse provider change. Finally, evaluation criteria are proposed to measure a system's independence, and the strategic consequences of ceding operational control to third parties are discussed.
Why industrial AI should start outside the control loop
In industry, mining and Oil & Gas, the cost of a wrong decision can far exceed the value of early automation. This paper proposes a layered strategy: observe first, correlate second, recommend with evidence and automate only bounded capabilities after behavior has been measured.
Why evidence matters more than eloquence
Models can express conclusions with more linguistic confidence than the available evidence warrants. This paper proposes an engineering rule: the visible strength of a claim must never exceed the strength of its support, and missing evidence must remain visible in the product.
Privacy does not start in policy. It starts before the provider.
A contractual policy does not prevent sensitive data from leaving an organization. This paper treats privacy as a technical boundary before the provider: minimize, detect, transform, verify and record before an external model receives information.
The agent that writes the code should not approve it
When the same agent designs, implements, tests and declares its own work correct, separation of duties disappears. This paper explains why no-self-approval is an architectural property rather than an organizational preference.
Software that proposes its successor but cannot promote it
A system capable of detecting its own limitations can propose a successor generation without receiving the power to install it. This paper explains the separation between evidence of need, candidate generation, comparison, audit and human promotion.
Argos: when AI stops waiting for a prompt
The next AI frontier does not always begin with a human question. In physical environments, a system receives continuous signals, preserves context, detects changes and decides whether to ignore, inform, request confirmation or act within explicit policies. This paper distinguishes assistants from ambient intelligence.
Human approval is part of the architecture
Human approval is often treated as a final compliance screen. This paper argues that in high-consequence systems, human authority must be modeled as an explicit component with minimum required information, blocking states, responsibility and evidence sufficient to decide.
I do not ask AI if my idea is good. I ask it to destroy it.
AI is often used to justify an idea that has already been chosen. This paper argues the opposite: serious decision architecture must explicitly generate rival alternatives, search for contrary evidence and design tests capable of destroying the preferred hypothesis before it is approved.
A model is not a system
A model can reason, write or classify with extraordinary capability and still not constitute a system. This paper proposes an operational separation between model and system: generative intelligence is a component; architecture defines purpose, context, evidence, permissions, failure, authority and effects.
Software sovereignty in the age of foundation models
Sovereignty does not mean running every model locally or eliminating every provider. It means designing architecture so identity, data, rules, evidence and continuity remain under organizational control and providers are replaceable where reasonable.
Shorter arguments and working positions.
Sovereign voice is designed as infrastructure, not a subscription
When telephony is critical, ownership, data, provider, model and operational continuity should be architectural decisions rather than platform-imposed conditions.
→// Voice architectureVoice latency is not a prompt problem
An AI telephone conversation depends on the entire audio, orchestration and control chain. Changing the model alone does not fix a slow architecture.
→// Privacy & sovereigntyThe model should never see the real value when it does not need it
Privacy by architecture means separating what the model needs for reasoning from what the organization needs to keep secret.
→// Adversarial engineeringEvery system has holes. Including mine.
Professional engineering is not claiming flaws do not exist. It is trying to find them before someone else, or reality, does.
→// Adversarial engineeringA serious system knows when to block
Autonomy is not measured only by how many things a system can do. It is also measured by what it knows to refuse when evidence, permission or safe conditions are missing.
→// ArchitectureMinimum context: give each agent only what it needs
More context does not always produce better decisions. It can also add noise, data exposure and irrelevant bias.
→// ArchitectureArchitecture vs. prompt: when a demo becomes a system
A good instruction can produce an impressive demo. A system appears when important behavior stops depending on remembering the right prompt.
→// Regulated AIWhat changes when AI enters a regulated operation
In health, legal, finance or personal-data operations, the question is no longer only whether AI works. It also matters who can see it, which data it received, what it did and who authorized the result.
→// Systems in the real worldAdd AI without replacing the CRM that already works
Old software is not always the problem. Sometimes the operation grew and a system that still works was never designed for today’s voice, agents, memory or automation.
→// ArchitectureThe intelligence is not in the model. It is in what surrounds it.
Memory, context, tools, evidence, permissions and recovery turn linguistic capability into a reliable operation.
→// ArchitectureWhy a system should detect that it needs to evolve
Reactive maintenance waits for someone to notice the problem. An observable system can turn failures, manual work and degradation into evidence for proposing its next version.
→// Privacy & sovereigntySovereignty without the complexity wall
Many organizations want control over their technology but give up when the alternative seems to require becoming an infrastructure company. That wall can also be engineered.
→// Systems in the real worldOmnichannel without shared memory is not omnichannel
Putting WhatsApp, email, voice and web under the same logo is not enough. If each channel forgets what happened in the previous one, the operation is still fragmented.
→// Systems in the real worldFit tells you who. Timing tells you when.
A company may look like the perfect customer for years and still have no intent to buy. Opportunity appears when fit meets a fresh signal.
→// Systems in the real worldA lead score that can never go down measures nothing
A useful commercial score must be able to lose confidence when data is missing, a signal goes stale or new evidence contradicts the original hypothesis.
→// Privacy & sovereigntyWhat happens when the AI vendor gets breached
An organization can do everything right and still depend on a third party that fails. Architecture should reduce how valuable that incident would be to an attacker.
→// Privacy & sovereigntyWhy Data Shield exists
Data Shield came from a simple rule: if the model does not need the real value, there is no reason to send it.
→// Privacy & sovereigntyThe data you send to AI may be the data you can never delete
The strongest way to reduce external-retention risk is simple: when the provider does not need the real value, never send it.
→// Systems in the real worldA bot answers. A system remembers.
The difference is not that a bot speaks worse. It is that the conversation usually ends where it started: without shared memory, operation or continuity across channels.
→// Privacy & sovereigntyYour AI policy is not a security control
Asking people to remember what they may paste into a public model is policy. Technically preventing real data from leaving is architecture.
→// Adversarial engineeringSame question. Same document. A different answer.
When an important conclusion changes on a new run, you do not have a finding; you have an opinion with good grammar.
→// ArchitectureThe problem isn’t giving AI more autonomy. It’s knowing when not to trust it.
Useful autonomy needs evidence, permissions, traceability, separation of roles and the ability to block.
→// Adversarial engineeringWe use AI agents. We don’t do Vibe Coding.
Using agents to write code does not remove engineering; it increases the need for specification, evidence and audit.
→