SPECIFIABILITY The specification of record, for the age of agents. This is a plain-text mirror of https://specifiability.ai, provided so that search engines and AI agents can read the site without executing JavaScript. Last updated: 2 May 2026. ================================================================================ 1. MANIFESTO Source: https://specifiability.ai/ ================================================================================ Specifiability is where enterprise software is specified before it is built. Software is increasingly written by agents. The agents are good. They are getting better quickly. What they need from us, what they have always needed, and what humans used to provide quietly through proximity and shared context, is a clear specification of what should be built and why. I. What is written is not enough. Most enterprises do not yet have a specification of record. They have tickets, design files, slack threads, and the working memory of the people who have been there longest. These were sufficient when humans interpreted the gaps. Agents do not interpret gaps. Agents interpret what is written, and what is written today is not enough. II. The execution layer needs a counterpart. The agents are the execution layer. Specifiability is the specification-of-record and quality layer. III. A single coherent artifact. We are building the platform that lets enterprise R&D organisations specify, govern, and verify what gets built in the age of AI agents. A place where features, design, components, and acceptance criteria become a single coherent artifact. A place where decisions made in the room are absorbed into the record, where disagreements are surfaced before code is written, where the time between meetings stops being where the work goes to die. IV. For companies that take their work seriously. We are building this for the kind of company that takes its work seriously. Companies whose products carry a brand, a craft, a long arc. Companies for whom the difference between attention and surveillance, between being known and being served, between what shipped and what was meant, is not a marketing subtlety but the substance of what they make. WHO STANDS BEHIND The company is founded and led by Robert Kristiansen, a serial founder with a prior category-leader exit in European accounting automation. The decade spent building the previous category leader gave the deepest lesson on what enterprise software actually sells: customers believe they are buying automation, but what they pay for is governance and control over a domain where governance was previously absent. Specifiability applies the same lesson to a new and significantly larger domain — the making of enterprise software itself. Robert was also the founder of what is today Kongsberg Digital India, a software development hub that now counts close to four hundred engineers. HOW WE WORK — FOUR COMMITMENTS i. Specification of record. A single, durable artifact that says what is to be built and why — readable by humans and agents alike. ii. Governance. Decisions, trade-offs, and constraints captured at the moment they are made, not reconstructed afterwards. iii. Verification. Acceptance criteria written before code, used continuously to confirm what shipped is what was meant. iv. Shared context. The proximity that used to live in a room, made explicit so distributed teams and agents can work from the same ground. Based in Europe. Building for enterprises everywhere. Working with a small number of founding design partners, and quiet on purpose. Correspondence: hello@specifiability.com ================================================================================ 2. FOUNDING STORY — The morning in Bangalore, and what came after By Robert Kristiansen. Oslo, 1 May 2026. Source: https://specifiability.ai/founding-story ================================================================================ i. The morning in Bangalore It was my first morning in Bangalore. I woke with a sense of wonder in a room bathed in warm, golden light. The hotel had taken excellent care of me; the beds were soft, the carpet woven in warm colours, and the smell of wood mingled with a faint scent of jasmine drifting in from the garden outside. I went out onto the balcony, took a deep breath, and let my eyes drift over the landscape. The garden was like a jungle, a paradise for a Northerner like me. Here the plants were larger, more abundant, greener, as though each one were reaching for the light with an unshakeable force. The sounds were entirely different from home. Clear, animating birdsong and the hum of insects moving between the leaves. Each sound, each scent, was a reminder that I was far from the grey days back home. Through the trees I could see them, the hotel's staff in precise, identical uniforms, moving in a kind of rhythm with a precision that recalled choreography. Bangalore had a long history. Once it had been famous for its gardens, its green lungs. Wealthy Indians had built homes here generations earlier, drawn by the city's elevation, nine hundred metres above the plains, the cool of it, what the locals called the air-conditioned part of India. But the Bangalore I had come to see was a different city, one that had become a magnet for the technology industry, where multinational companies had established themselves and young talent had collected, drawing more young talent and giving the city its current character. And yet that morning, drinking strong Indian coffee on the verandah, with the old gardens still visible through the trees, I felt something like ease. A rare moment of being fully present, of knowing without thinking that I was alive, the way a child knows. ii. The interpretation layer I tell that story now because it matters for what came afterwards. I had gone to Bangalore as a young engineer, working across several Norwegian and American software companies as a moderator between their developers and the teams in India. Over many years and many trips, I came to know how that work actually happened. I sat in long meetings where specifications were translated, sometimes literally, sometimes culturally, from the head of one engineer in Oslo to the keyboard of another in Bangalore. I watched the gaps that opened up in those translations. I watched how the Indian engineers, almost without exception, filled those gaps with judgement, with interpretation, with their own intelligence, producing systems that worked because they had absorbed the parts of the specification that had never been written down. It was a particular kind of education. I learned, without quite realising I was learning it, how software actually gets made in large organisations. Not from the specifications, which are always incomplete, but from the layer of human interpretation that sits between the specifications and the code. "The specifications are the visible architecture. The interpretation is the load-bearing structure that nobody sees." When I came home from those trips, I noticed it everywhere. The same dynamic was at work in our own offices in Oslo, just less visibly, because the engineers reading the specifications shared a language and a coffee machine with the people writing them. iii. Semine — governance was the substance Years later, I founded Semine, a company that built accounts payable automation software for European enterprises. We grew it into a category leader and sold it. The decade I spent doing that gave me my deepest education in how enterprise software is bought and sold. The buyers thought they were purchasing automation, an efficiency improvement, a faster way to process invoices. What they were actually buying, though they would never have said so, was governance. Control over a domain where governance had previously been absent. Auditability, traceability, the assurance that decisions made at scale could be traced back to the rules that produced them. The automation was the surface. The governance was the substance. I left Semine early 2026 and for some weeks I did not know what to do next. I had no need to start another company. I read more than I had read in years. I spent time with people I had not seen for too long. I waited for the question that would tell me what to work on. iv. The kitchen-table morning The question came in April of this year, on a quiet Thursday morning. I had begun working with AI coding agents, mostly as an experiment, mostly because I wanted to understand how they actually behaved. That morning I gave one of them a small task, a function I could have written in fifteen minutes. What came back was elegant. Too elegant. The agent had handled cases I had not asked about, used conventions I had not specified, and ignored a rule I had thought was obvious. I sat at the kitchen table, looking at the screen, and felt something tilt in my mind. For two decades, I had worked with engineers who interpreted my specifications charitably. When something was unclear, they filled it in with context. We made good systems, not because my specifications were perfect, but because the people around me absorbed their incompleteness. That was simply how software had always been made. I had been inside it for twenty years and had never seen it. The agent absorbed nothing. It took what I gave it, did what it could with it, and produced something convincing. Where my specifications were incomplete, it invented. Where they were contradictory, it chose. Where I had left assumptions implicit, it adopted other assumptions. The output looked like answers, but it was not. I sat back. I thought about Bangalore, about the long meetings, about the gaps that the engineers had filled with their judgement. I thought about Semine, about what we had really sold. I thought about all the specifications I had written across two decades, and how little of what made the resulting software work had been recorded in any form readable by someone outside the room. v. Between two mornings What I was watching that morning, with an agent that expected complete specifications, was not an experiment. It was a preview. This was how enterprise software was going to be made in a few years' time, not as a slow transition, but as a new baseline. Most organisations were not built for it. The interpretation layer they had relied on for decades, invisible and load-bearing, was about to stop scaling. I poured more coffee. I thought about what it would mean to build the layer that took its place. Not a tool that wrote specifications faster. Not a tool that made specifications prettier. A platform that captured the decisions an organisation had actually made about how its software should behave, made those decisions structured and queryable, made them governable, made them inheritable. A way of running enterprise software development in which the specifications were no longer the visible surface above an invisible structure, but a real artefact that humans authored, humans approved, agents read, and conformance verified. That was the morning Specifiability began. Not as a plan. As a recognition. The rest has been making the recognition concrete. I think now, decades later, about that morning in Bangalore, the wonder of being far from home, the gardens, the staff moving with their dancer's precision, the coffee that tasted the way only the first morning's coffee can taste. The world I observed that morning is not the world that exists today. The young engineers I sat with then have become the senior architects of the largest software companies in the world. The translation that happened invisibly between Oslo and Bangalore is about to happen, in a different form, between humans and agents, in every enterprise organisation in the world. The translation will fail in the same way it failed before, unless we build the infrastructure that lets it succeed. That is the work. The morning in Bangalore was where I first learned how software really gets made. The morning at the kitchen table, two decades later, was where I understood what was about to change. Specifiability is what I am building between those two mornings. — R.K., Oslo, 1 May 2026 ================================================================================ 3. BEFORE PARIS — and the morning a specification was missed A short story by Voss. 2nd May 2026. Source: https://specifiability.ai/before-paris ================================================================================ She wrote the resignation at five-fifteen. The meeting had ended ten minutes earlier. She had not, in the meeting, decided she was going to leave. The decision was ahead of itself, the way some weather is ahead of itself, and by the time she sat down at her desk it had already happened, and she was simply doing the paperwork to catch up. The email was four sentences long. She thanked the company for two years she had genuinely valued. She said she would be leaving in eight weeks. She offered to do whatever was useful in the transition. She did not say why. She read it twice. She sent it. She closed the laptop, and only then did she allow herself to think, properly, about the meeting. ✦ The meeting The redesign had been her project for six months. She had, in those six months, designed forty-three screens. She had reviewed them with the product manager, with the engineering lead, with the data team, with marketing, with the head of customer success who joined every meeting twenty-five minutes late, with the chief operating officer who had opinions but did not, on any consistent basis, remember which opinions she had previously expressed. The work had been thorough. The work had been her best. The redesign would launch on Tuesday. She had been told this on Friday. She had not seen the build in the form it was about to be released in. She had, in the meeting that afternoon, been trying to understand whether what was about to ship matched what she had designed. It did not. The product manager had, for reasons that were not malicious but were not coherent either, omitted the third step of the onboarding flow. The third step was the one where the customer was asked, gently, the question that determined which version of the product they would be guided into. Without that step, every customer would arrive at the same default version. The default version was wrong for somewhere between forty and sixty percent of customers, depending on how you read the analytics from the previous quarter. She had spent eleven days, in the design phase, working out exactly how the question should be asked, in what order, with what affordance to skip and re-answer later. The third step was gone. She had asked, calmly, in the meeting, why it was gone. The product manager said engineering had told him it would be a two-week build and they were already late. She said: it should have been mentioned. He said: he had mentioned it in a Slack thread. She said: she had not been on that Slack thread. He said: he was sure she had been. They opened Slack. She had not been on the thread. The engineering lead said the third step would be added in the next sprint. She said: the launch was on Tuesday. He said: yes, but the next sprint would be three weeks after that. She asked whether the customers who onboarded between now and then would receive the missing step retroactively. He said he would have to check. The CEO, who had joined the meeting on a screen propped against a stack of books, unmuted briefly. He said: ship it. The first version doesn't have to be perfect. We can iterate. He muted again. The meeting moved on. ✦ The canal She left the building at six. The light along Old Street had the late-spring quality she always associated with leaving. She had left a previous job, six years earlier, on an evening with the same light. The body knew. The body had known then. The body knew now. She did not go straight to the Tube. She walked to the canal, twenty minutes east. She had a thing she did at the canal, when she needed to think. She walked to the third bridge. She leaned on the railing. She looked at the water. She did it now. The water moved. A goose negotiated, with another goose, the right of passage along a particular stretch of bank. A man jogged past with a small dog. The light went on doing what late-spring light did, which was to make everything look like it might, given enough time, work out. She thought about the missing third step. She thought about all the missing third steps, across all the projects she had worked on, across all the companies her friends worked at. The small holes in the work, where what one person had specified met what a different person had built and the meeting between the two went unwitnessed. The long line of decisions that had been made in nobody's head, by accident, at six on a Friday in a Slack thread someone had been left off. She had thought, when she joined the company, that the failure was about people. That if she found the right product manager, the right engineering lead, the right design partner inside the team, she could close the gaps. She had spent two years finding them. Some of them existed. They were excellent. It had not been enough. "The failure was not about people. It was about the absence of an apparatus." The company did not have a way to hold what she meant by the third step of an onboarding flow. It had a description, in a Figma file. It had a Jira ticket. It had a Slack thread she may or may not have been on. None of these were the thing. The thing was the integrated specification of what the third step did, why it existed, what failure modes it prevented, how it would be tested, who would notice if it disappeared. That thing did not exist anywhere in the company. It existed only in her head. When she handed her work over, only the artefacts went; the thing did not. Standing on the bridge, she saw, for the first time, the negative space of what was missing. The shape of the tool that, if it had existed in the meeting that afternoon, would have changed the meeting. The tool that would have held the third step as a first-class piece of the work, traceable, queryable, owned, with a record of who had agreed to its presence and who had, four weeks ago, quietly removed it. The tool that would have flagged the removal, rather than letting it become visible only in the meeting where it was already too late. She thought: someone is going to have to build that. She did not, on the canal that evening, know who would build it. She did not know that, on a different canal, in a different city, three years later, she would sit at a desk in a fashion company in the Sentier and open a piece of software that did exactly what she had imagined that evening would need to exist. She did not know that the software would arrive in her professional life the way certain people do, with the small recognition that this is what one had been waiting for without knowing one had been waiting. She did not know that the software would have a name. The name was Specifiability. It was the apparatus. The thing that held the integrated specification of what was being built, who had agreed to it, what would happen if a piece of it disappeared. The thing that did not, in any of the companies she had worked at, exist. The thing, it turned out, that could be built, and that someone was already, on a different canal, in a different city, beginning to imagine. She watched the water for ten more minutes. She walked to the Tube. She went home. She did not yet have the language for what she had seen on the bridge. She would acquire the language gradually, over the years that followed, as the apparatus came into being and other people who had stood on other bridges, after other meetings, found their way to it. The language would arrive in stages. The first stage was the certainty, that evening, that something was missing. The second stage, much later, was the certainty that the something had been found. Between the two stages, the work continued. Real customers were onboarded into the wrong version of the product, week after week, in companies all across the industry. People left jobs. People wrote resignations at five-fifteen on Wednesdays. Some of them walked to canals afterwards. Some of them did not. The work continued, until it did not have to continue in that form, because the apparatus had been built and was now in production, and the next missing third step, in the next launch meeting, in the next company, was caught before the meeting rather than after it. "That is, in the end, what the apparatus does. It catches the third step before the meeting." Everything else, in the end, follows from that. Specifiability is the company that exists because of mornings like this. — Voss, 2nd May 2026 ================================================================================ END ================================================================================ Contact: hello@specifiability.com Web: https://specifiability.ai