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.
13 practical guides · 11 technical papers · 24 engineering notes · architecture, evidence, sovereignty, controlled evolution and real-world systems
Straight answers to the questions companies ask.
AI for marketing in small businesses: what to automate
How a small business can use AI for marketing: content drafts with human editing, segmentation from CRM data, campaign follow-up, lead qualification, reporting, and visibility in search engines and AI assistants.
→// Practical guidesAI customer service: a practical guide for companies
What AI customer service handles well, what it should not handle alone, how it works on WhatsApp, web, email and phone, when to hand off to a person and how to measure whether service improves.
→// Practical guidesAI for real estate agents: practical uses for agencies
How to use AI in a real estate agency: answering portal and WhatsApp inquiries, matching buyers with listings, booking viewings, following up with a real estate CRM and protecting client data.
→// Practical guidesCustom CRM cost: what drives the price of a custom CRM
Custom CRM cost depends on scope, integrations, data migration and maintenance. What to look at when comparing it with a subscription CRM, and when building your own is not worth it.
→// Practical guidesAI for law firms: practical uses and risks
What artificial intelligence can do in a law firm today, the risks it brings (confidentiality, invented citations, professional responsibility) and the rules to set before using it.
→// Practical guidesHow to appear in ChatGPT and other AI assistants
What a company can do so ChatGPT, Gemini or Perplexity mention it when someone asks about its field: clear pages, direct answers, consistent facts and crawling permissions, with no magic promises.
→// Practical guidesDigital transformation for small business: where to start
A practical guide for a small business to organize its digital transformation: what to look at first, what to fix quickly, in which order to move and which mistakes to avoid.
→// Practical guidesInventory spreadsheet or inventory management system: when to switch
The signs that an inventory spreadsheet is no longer enough, the options available (a better sheet, a standard system or a custom one) and how to migrate without losing control of stock.
→// Practical guidesAI in logistics: practical use cases for transport and distribution companies
Where artificial intelligence helps a logistics company, what data it needs, where it should not be used and how to start with a first, well-bounded and measurable project.
→// Practical guidesn8n vs custom development: when each one fits
An honest comparison between automation tools such as n8n, Make or Zapier and custom development: volume, complexity, sensitive data, hosting, maintenance and who owns what.
→// Practical guidesWhatsApp Business API guide: access, rules and pricing model
A practical guide to the WhatsApp Business API: how it differs from the app, requirements, steps to get access, templates, the 24-hour window, the pricing model and what a WhatsApp chatbot on the API can do.
→// Practical guidesWhat is an AI agent? AI agent vs chatbot explained
An AI agent does more than answer: it queries systems and carries out tasks within defined permissions. This guide explains how it differs from a chatbot and from automation, with examples and limits.
→// Practical guidesAI implementation cost: what drives the price
AI implementation cost has two parts: building the system and running it. This guide explains what drives each one and how to start with a small, measurable project.
→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.
Logging is not enough: AI control has to happen before action
When AI can create real consequences, post-action logging is not enough. Evidence, authority and reversibility need to be checked before execution.
→// Technological sovereigntySovereign 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.
→