THE FOUNDRY MODEL
A firm that builds an industry’s software, then runs it.
A vertical AI foundry identifies an industry that software has underserved, builds the product that industry runs on, and operates that product for the long term. All three verbs matter, and the third is the one most firms drop. We do not build a system and hand it over. We run it.
The distinction is easiest to see against the models it is mistaken for. A venture studio spins companies out and steps back; the operating discipline leaves with the founding team. An agency builds to a brief and bills for the build; the product depends forever on the people who first assembled it. Horizontal SaaS builds one tool for every industry and reaches each of them only in part, because a general tool cannot hold a specific standard. A foundry does the opposite of all three: it commits to a single vertical, owns the product, and stays to operate it.
That commitment is not a preference. It is the source of the work’s value. A vertical worth entering is one where the standard is high, the workflow is real, and the conditions of the setting are unforgiving — where an approximate answer is worse than no answer. You do not learn to hold that standard from the outside, and you do not hold it by shipping and leaving. You hold it by operating the system every day, in the setting it was built for.
NOT TO BE CONFUSED WITH
- Venture studio
- Spins ventures out and steps back. We stay to operate.
- Agency
- Builds to a brief and bills for it. We own the product.
- Horizontal SaaS
- One tool for every industry. We build for one.
THE ALNAIRE METHOD
Six stages, in sequence.
The order is true, not presentational. Each stage depends on the one before it, and the last two are where a foundry earns the name.
- 01
Identify
We start from the vertical, not the technology. We look for industries that run on a written or spoken record, a regulated workflow, or an aging estate — work that software has reached only in part, or reached with tools built for a general case that the vertical does not fit. The question is never what a model can do. It is which industry is underserved, and whether we can hold its standard.
α — PENAVIS
Legal transcription is such a vertical: courts run on the verbatim record, skilled transcriptionists are scarce, and demand does not fall. Penavis was built for that gap.
- 02
Embed
Before we build, we learn how the work is actually done. Domain research is not a discovery phase to be cleared; it is where the product is decided. We map the standard the vertical is held to, the point at which existing tools break, and the conditions the real setting imposes that a general tool never anticipates.
α — PENAVIS
Malaysian proceedings move between Bahasa Malaysia and English within a single exchange, alongside legal terminology and names no general model has seen. A system that ignores that reality does not survive contact with the courtroom. Embedding is how we knew.
- 03
Build
We build the product ourselves, and we build the workflow and the interface together. Owning the build means the tool is designed for how the work is done rather than adapted to it afterward, and it means the product has a roadmap behind it rather than depending on the team that first assembled it.
α — PENAVIS
Penavis runs on VTTE and TRE — transcript editors built in-house that hold the audio, the draft, and the correction in one controlled surface, so an editor verifies against the source rather than retypes from it.
- 04
Deploy
We deploy on the buyer’s terms, not the vendor’s. For enterprise and government buyers, where sovereignty over communications and data residency are requirements rather than preferences, that means the choice of where a system runs belongs to the organisation. We modernise around live operations instead of demanding they stop.
β — TELIXIS
TELIXIS runs on-premise or in the cloud, and spans PABX and IP telephony so a legacy estate is modernised in place — connecting new capability to existing systems on a timeline the organisation sets, without a rip-and-replace.
- 05
Operate
We operate what we build, long-term. This is the line that separates a foundry from a studio or an agency: we do not hand a system over and move on. Running the product in daily production is how the standard is held, how the workflow is protected, and how the discipline of the handoff between machine and human survives contact with volume.
α — PENAVIS
Penavis is a production pipeline in daily operation — the machine handles volume, trained human editors hold the court-grade standard, and neither step is optional. The quality lives in the discipline of running it.
- 06
Certify
A system that holds a legal record or carries an organisation’s voice traffic has to be trusted with the data as much as it is trusted to do the work. We hold our ventures to a formal assurance posture rather than an informal one, and we say where that posture stands plainly.
PROGRAMME
Penavis handles data under controls aligned to ISO/IEC 27001, with certification in progress. Across the foundry we run an ISO/IEC 27001 and ISO/IEC 42001 programme — information security and AI management — as a standing commitment.
THE SHARED PLATFORM
Every venture inherits the same foundations.
A foundry is worth more than the sum of its ventures because the ventures are not built from nothing each time. They stand on a common platform — the pipeline that runs the work, the discipline that holds its quality, the assurance posture that lets a regulated buyer trust it, and the infrastructure it deploys on. A new venture starts from a foundation that is already proven in operation.
- AI pipeline
- A production pipeline, not a model in isolation. Automated systems handle volume; the platform is built around the handoff to the people who hold the standard, because in a setting that carries weight a confident error is worse than an obvious gap.
- Human-in-the-loop QA
- Trained human review is a designed step in the workflow, not a fallback. The machine handles the volume and the humans hold the standard; neither step is optional, and the tools are built so the standard is something the workflow protects rather than something a reviewer has to remember.
- Compliance posture
- A formal assurance posture rather than an informal one. We run an ISO/IEC 27001 and ISO/IEC 42001 programme — information security and AI management — with certification in progress, and we state where it stands plainly. A system that holds sensitive records has to be trusted with them.
- Infrastructure
- Deployment on the buyer’s terms. Ventures run on-premise or in the cloud, so an organisation that must keep data and traffic inside its own boundary can, and they integrate with the estate an organisation already has rather than demanding it be torn out first.
WHY VERTICALS
Depth is the defensible position.
01 — DOMAIN DEPTH
A horizontal tool competes on features anyone can copy. A vertical product competes on understanding an industry that took years to learn. The defensibility is not the code; it is knowing where the work breaks, which condition the setting imposes, and what standard the output is actually held to — knowledge you only get by building and operating inside the vertical.
02 — REGULATED MARKETS
Regulated and government markets reward the firms willing to meet their requirements and shut out the ones that treat them as optional. Sovereignty over data, residency inside a boundary, and a formal assurance posture are not features to add later; they are the price of entry. A vertical built for those conditions from the start holds a position a general platform cannot reach.
03 — WORKFLOW OWNERSHIP
When the product is the workflow an industry runs on, and we operate it, we own the relationship at the point where the work actually happens. That is a deeper position than a tool a customer could swap. The workflow, the interface, and the standard were designed together, and they are held in operation — not delivered and left.
We identify the vertical, build its system, and stay to run it.