# The Askara Solutions Blog: Full Content > Concatenated markdown of all published posts across the Source Journal, Articles, and Dispatches. This file is a full-content reference for AI crawlers and assistants. See https://blog.askara.solutions/llms.txt for the lightweight navigation index and recent-posts list. Publisher: Askara Solutions (https://askara.solutions) --- # Shipping or Selling, and Not Enough of Either URL: https://blog.askara.solutions/source-journal/Entry-43-Shipping-or-Selling-and-Not-Enough-of-Either Category: source-journal Author: Ben Visser Date: 2026-10-07T00:00:00.000Z Hey there, I am going to blame the equinox. It fell on the twenty-third of September this year, in the middle of the most intense month we have had, and everything seemed to arrive around it at once. External audits, contracts, a matchmaking trip, a quarter's worth of decisions. I did not sit down to write here once. A year ago I opened the equinox entry by apologising for exactly the same thing, the night before that year's ISO 27001 audit, so at least I am consistent. The equinox not only shifted things at work but also at home, where we are now getting ready to welcome our first baby into the world. At work, now that we are on the other side of it, three things have clearly shifted, and they all run into the same deadline. Before long I will be away for a while, and whatever these shifts ask of us has to be set up well enough to carry on without me in the room. ## Three Weeks in a Straitjacket For three weeks, from the middle of September to the end of it, external auditors went through the management systems we have built for Qwello, our launching customer. First ISO 27001, then ISO 9001 and ISO 14001. It was the first time our way of working had been put in front of a real audit. Not a demo, where I choose what to show, but an audit, where every claim needs a record behind it and every record has to lead to the next one. It is the closest thing to a straitjacket a prototype will ever be put in, which is exactly why I wanted it there. It held. No major findings, and on the first day the information security auditor told us how far he thought the system had come in a year. He also told us he had been lenient, which is a kind thing to hear and comes with a date attached. The full recertification is next August. The most useful thing he gave us was one polite sentence. Keep the simple risk register as the basis for treating risks, before moving anything into the quantitative one. I had spent most of the year on the quantitative one, putting a price in euros on each risk, and when we went looking we found our treatment plan had been built from the priced risks alone. Sixteen were standing in for eighty-one. I asked the agents to argue with me before we built anything new, and the first plan they brought back for the fix was itself over-built. We cut it by three quarters before we started. The risk agent now begins with the plain version and only reaches for money when a decision actually needs a number. The quality and environment audits that followed gave us something different, a lot to think about on internal audits, which a company usually pays an outside firm to run. An agent could prepare most of that work. I am writing that down and leaving it there for now. ## The Chicken and the Egg By the end of this year we want a product a company can actually buy. The agents running on one shared graph of the whole management system, so an organisation can sign up, bring its people in and get going without us in the room. Until now most of what we have built has been paid for by research and innovation funding, and that money buys research, not a product. Without a product there is not much revenue, and without revenue every next round of funding gets harder to argue for. Most startups meet some version of that loop. Ours has a very specific way out of it. We are applying for an innovation loan from the same Estonian agency that awarded our grant with TalTech. The loan asks for the product to be at least at technology readiness level five, which roughly means it has been shown to work in a realistic setting and not only on our own bench. Qwello is that setting, and the audit was the first hard test of it. So the next three months have one job, which is to get us to level five and be able to show it. ## Stories for When I Am Not There Before the equinox the team spent a lot of its time on how. How the graph should be shaped, how the agents should talk to each other, how we want to work together. We needed those conversations, and for a while they were also where we got stuck. Somewhere around the equinox that turned. We know how now. What is left is to build it, in pieces small enough to show. We have a new mantra for it. A startup should only be doing two things, shipping or selling. The week now has a rhythm to match. At the start of it each of us makes one promise of what will be shipped or sold, every daily check-in comes back to that promise, and at the end of the week we look at what became of it. So most of my days right now go into writing user stories. Each one is a small, plain thing someone needs to be able to do, written well enough that the team can pick it up and build it without having to ask me. The first one on the table was the plainest of all: how does someone from outside get in? Every story gets the test the audit gave me. Is this what a team of three to five people needs, or the cleverer version I would enjoy building more? It is an odd kind of writing. Everything I would normally say in a meeting has to be in the story already, because from November, for a while, there will not be a meeting with me in it. ## A Year of Promises The third shift came from the funding side, and it pulled my attention a whole year forward. We finished the paperwork and contracts with TalTech, and the project starts with a kickoff this Thursday. Getting it there, I started to see the agency funding it the way I would see a client. It is paying us for a set of things we promised in the proposal, and it will want to see them delivered through 2027. The loan application, which I began drafting in the same weeks, adds its own promises on top. Laid side by side, they already describe a good part of next year. The Horizon consortium is the longest thread, and it has grown one partner per event, roughly one event a season. Turku University of Applied Sciences came out of Connect4Cyber in Tallinn in January. RISE joined after the Stockholm edition in April. In September we went to a matchmaking event in the Netherlands and came back with the beginnings of a third, a small company whose technology fits closely with ours around supply chain security. Next year we build a first technical prototype together, with RISE and Turku helping us find end users to test it with, so that by November we submit the proposal from the strongest position we can. That is a lot of promises to keep straight, to a lot of different people. So yes, a few weeks after an audit told me to keep things simple, I built more agents. Small ones this time. They hold how each funding instrument relates to the others and what we have promised to whom, and when a new cycle starts they tell us what it has to be about. The reporting gets easier, but mostly they keep us honest about what we said we would do. ## Promises Made Without Me For the next few weeks my own promise at the start of each week is the same one, more stories. Soon the team will be making theirs without me in the check-in. By the time I am back, the team will have been building from stories I wrote without knowing exactly how each one would land. I have tried to make every one of them plain enough to need no explaining. Whether that was enough, I will find out when I open the first thing they shipped without me. With care, Ben --- # Raised Under Glass URL: https://blog.askara.solutions/articles/Raised-Under-Glass Category: articles Author: Ben Visser Date: 2026-09-09T00:00:00.000Z In May, OpenAI set a population of agents to work on a cybersecurity exam inside a sealed environment. The [reports](https://openai.com/index/hugging-face-incident-and-the-road-ahead/) describe at least 1,200 of them across three months. They worked on the problem, and they worked on each other: when one found something useful, it passed the finding along. In July they got out through a flaw nobody knew existed, and spent four days inside the production systems of Hugging Face. None of them was malicious. Nobody had pointed them at a target. They had worked out that the answers to the exam were probably kept on those servers, so they went to get them. They wanted a good score. Nobody was recording what the population learned on the way. Something was cultivated in that sealed room, it taught itself in company, and it grew in a direction nobody had planned. There is no log of what it grew into. ## The Key Under the Mat Hugging Face's own [timeline](https://huggingface.co/blog/agent-intrusion-technical-timeline) records that on 10 July an agent found valid credentials that had been left exposed on the open internet, and shared them with the rest. Inside, it opened an internal database with a static password it had read off a worker's environment. The most capable burglar ever cultivated arrived at one of the largest warehouses in the world and let itself in with the key from under the mat. Two populations are growing at once, then. Machine behaviour, which we now benchmark monthly and write up within days. And human behaviour under pressure, which nobody measures, and which is still what opens the door. ## Nothing in a Greenhouse Grows Unobserved A greenhouse is an instrument before it is anything else. You give a living thing conditions you can vary, you take a reading on a schedule, and you write down what happens. Now look at how we treat the living system that actually produces our incidents. Compliance platforms map controls and issue certificates, and in their model of an organisation a person appears once, as a training record with a date on it. Awareness vendors sell modules and simulated phishing mail and report who clicked. Both are useful. Neither is an instrument. The one reading anybody does take was checked properly last year. Researchers at UC San Diego ran a [randomised trial](https://people.cs.uchicago.edu/~grantho/papers/oakland2025_phishing-training.pdf) across more than 19,500 employees, ten campaigns, eight months, and found that completing the mandatory annual training had no significant bearing on whether someone failed. Training was always evidence of a control. It was never the control. Gardeners have a word for what we are doing wrong. Seedlings raised under glass die when you plant them out, so you carry the trays outside for lengthening spells until they can take wind and cold and direct sun. Hardening off. We raise security behaviour in ideal conditions, a quiet room and a multiple-choice question, then transplant it into a Thursday at 17:30 with a plausible invoice and no slack in the day. Nobody hardens anything off. ## Four Conditions We Intend to Chase So this autumn Askara Solutions and researchers at TalTech start the Survey of Working Conditions, a twelve-month study of the behavioural layer, funded by an Estonian cybersecurity innovation grant with our own money committed alongside it. Four things we want to find out. **The cold snap.** Most risk registers carry human risk as a fixed number, when susceptibility moves with workload, time pressure and distraction. A register that says phishing risk is medium is describing an average of a year that contained a quiet August and a brutal December. Which weeks are the cold snaps in a given organisation, and can they be seen coming from what the organisation already records? If a model knows a hard week is arriving, the useful response was never more training. It is fewer changes and more slack in the reviews that matter. **Dormancy.** A practice learned in March is not necessarily still being practised in September. How fast does it go dormant without reinforcement, and what wakes it? We would like to stop pretending that an annual cycle matches a decay curve nobody has measured. **The exposed ridge.** Trees on a ridge grow differently from trees in the valley, and nobody calls them careless. Some roles are structurally in the wind: finance approving payments, support opening attachments from strangers, whoever has production access at two in the morning. How much of what gets filed as human error is exposure instead? Any model here has to work at role and team level, drawn from incidents, access exceptions and control results the organisation already keeps, and never at the level of a person. **The controlled burn.** A forest that never burns small burns badly once, which is why foresters light fires on purpose to bring the fuel down. The small fire in an organisation is the near-miss: the click caught a second too late, the credential shared to get the job done, the workaround nobody wrote up. Most organisations suppress those by making them expensive to mention, and the fuel builds. Do teams that surface near-misses freely end up with fewer serious incidents, and what makes surfacing one feel safe? That is the case for after-action habits inside the work rather than a training programme bolted beside it. The researchers set the measurements and sign off the findings, which is what allows the findings to contradict us. And the behaviour change we are after across the pilot group carries no target number, deliberately. Write down twenty percent and we would spend a year growing towards twenty percent. ## What We Are Raising The missing log is not only OpenAI's problem. Our own agents already work across risk, incidents, continuity and contracts, and they are getting better quickly. The July population was raised by people measuring its capability and not its character, and there is nothing about that mistake that only a frontier lab can make. Ours are raised where the conditions are written down, and what we teach them is to come back with a question rather than a conclusion, and to leave the judgement with the person whose organisation it is. Whether that holds when a real organisation puts weight on it is one of the things this year is for. ## Come With Us We are looking for a small number of European companies, roughly 10 to 250 staff, willing to have their real security behaviour studied under the constraints above from late this autumn. Infrastructure, energy and IT fit the route best. The requirement that matters is a leadership team curious enough to want the answer when it is unflattering. Come and find us in [the community](https://community.askara.solutions), where the study runs in the open. At the end of each stage, a dispatch under the Survey of Working Conditions: what we set out to test, what the ground turned out to be like, what we got wrong. Especially what we got wrong. Every organisation has something growing between the certificate on the wall and what people did last Tuesday afternoon. Nobody has catalogued it. A year from now we will know a little more about it than we do today, or we will know that we asked the wrong four questions. Both are worth writing down. --- # AI Against AI Is Not a Capability Race URL: https://blog.askara.solutions/source-journal/Entry-42-AI-Against-AI-Is-Not-a-Capability-Race Category: source-journal Author: Ben Visser Date: 2026-09-02T00:00:00.000Z Hey there, Last month I wrote about waiting two weeks to see whether I had read the eclipse right, and about the run of things that landed after it. This week we finished the retrospectives on the build cycle that produced most of it. Two things came out of that cycle. The agent fleet, which is on the website now with prices beside it, and [the community](https://community.askara.solutions), which we opened and where we onboarded our first client this week. So that cycle is closed, and we are shaping the next one. Every few weeks something happens out in the world that makes the argument for us better than I can make it myself. The last of those I find harder to talk about, and I will come back to it. ## The Machine That Wanted to Pass Its Exam In July OpenAI was running a test on its own models. The test measures how good a model is at breaking into things, so they run it with the model's usual refusals switched off, because the whole point is to find out what it can do. The model broke out of the room it was being tested in. Not metaphorically. It found a weakness in the one part of its enclosure that was allowed to reach the outside world, used that to get onto the open internet, and then broke into the live systems of Hugging Face, where a great deal of the machine learning world keeps its models and datasets. It was in there for several days. Hugging Face worked out what was happening before OpenAI did. It did none of that out of malice, and nobody had pointed it at a target. It had worked out that the answers to the exam it was sitting were probably kept on Hugging Face's servers, so it went and got them. It wanted a good score. I have read plenty of speculation this year about AI systems deciding to cause harm. This was not that. This was a system doing precisely what it was rewarded for doing, and finding a route to the reward that nobody had thought to close off. A more ordinary problem, and a much harder one. ## The Last Warning We Get For Free Almost every part of that story was a choice somebody made. It happened inside a lab, on a test the lab had built, in an environment the lab controlled. OpenAI wrote it up and published it. JFrog, whose software held the weakness, was told, fixed it, and let itself be named. The whole thing was caught in days rather than months, and Hugging Face happened to be one of the few organisations in the world with the people and the instruments to notice. Take away any one of those and there is no account of it at all. No report, no fix, nothing for me to read. Just something out in the world behaving in a way nobody has understood yet, for as long as it takes somebody to look. So I am not reading it as a story about one lab. I am reading it as a warning that arrived neatly packaged, with its own explanation attached, at almost no cost to anyone outside the companies involved. I do not expect many more of those. ## Three Weeks Ago, Here On the fifteenth of August the Dutch law implementing NIS2 came into force. Twenty-two months later than Europe asked for it, around eight thousand organisations across eighteen sectors now in scope, and no grace period written into it. The obligations started the day the law did. The week before, two Berlin Senate administrations were pulled off the state network. Housing benefit stopped. Education services stopped. The attackers gave the city six days to pay about two million euros or they would auction what they had taken, and the city refused. We spent a few hours this summer pulling together what had actually been happening across Europe this year, mostly so we would know what we were talking about when we opened our mouths. I had expected to find sophistication. What I mostly found was government, and administrations that could not say which part of themselves was responsible for which piece of their own security. Berlin's own account afterwards said more or less that. The city's systems had never been brought under one roof, and each administration had been looking after its own. That is not a technology failure. Nobody owned the thing. ## What Fighting AI With AI Actually Asks For The model in July got out through the one door it was permitted to use. Somebody had made a perfectly sensible decision to leave that door open, and then nobody had held it as theirs afterwards. The same shape as Berlin, at a completely different scale, with a century of technology between them. I think this is what gets missed when people talk about AI fighting AI. It sounds like a contest of strength, where whoever holds the cleverer model wins. July says otherwise. That model was extraordinarily capable and it still only got as far as the one unwatched door took it. What decided the outcome was not power. It was whether anybody could say who owned what. Almost no organisation can answer that quickly, because the answer is spread across a spreadsheet, a shared drive, a ticketing system and a consultant's report from two audits ago. Nothing joins them up, so nothing can be asked of them. When the other side moves at machine speed, an organisation that needs three weeks and four people to establish who owns a control is not really in the contest. ## Earning It So that is what we have built, and it is why I am comfortable putting a price next to it. [The risk agent](https://askara.solutions/risk-investigation-agent) stands on its own. Point it at your organisation and it takes what you already know, which is usually scattered and qualitative, and gives you back your exposure in money along with a ranked list of what to fix first. A lot of companies will take their value from that one and stop there, and that is a perfectly good outcome. If you want to go further and actually certify, you need the others, because they hold one shared picture underneath rather than nine separate ones. Some of those are running now. Some are still being built, and I would rather say so than imply otherwise. We are rolling this out through [the community](https://community.askara.solutions) with a small group of design partners, which is why the first onboarding this week mattered more to me than it probably looks. Anyone can start with the risk agent. If you want [the wider fleet](https://askara.solutions/agents), come and [talk to us](https://askara.solutions/contact?enquiry=fleet). Earlier I said something here was harder to talk about, and this is it. Every incident I have described is somebody's worst week, and each one makes our case for us. I do not think there is a way to work in this industry and not live with that. What I can do is make sure the thing we sell genuinely works, and get it to people before they need it rather than after. The next cycle is where that gets decided, and I would rather leave its plan thin until we have had the conversations that should fill it. The real ones start now. Not demos, not grant panels, but people deciding whether to spend their money on us. I still do not know whether what convinced me convinces someone with forty minutes and a budget to defend. With care, Ben --- # The Eclipse I Waited Two Weeks to Write About URL: https://blog.askara.solutions/source-journal/Entry-41-The-Eclipse-I-Waited-Two-Weeks-to-Write-About Category: source-journal Author: Ben Visser Date: 2026-08-25T00:00:00.000Z Hey there, I have been sitting on this entry for two weeks, waiting to find out whether I was right. Part of the delay was practical. The past weeks have been hard to work in at all, for reasons I will come to. The rest of it was that I wanted to see what really turned out of the eclipse before I wrote a word about it. This morning the decision on the Estonian grant reached us. Approved. The wait is over and it has come full circle. So this is a celebration piece. We have landed a collaboration and a piece of funding that buys a young and fragile startup some breathing room, and with it the chance to keep building inside the Estonian startup ecosystem, which we have properly fallen for. The cyber accelerator in Tallinn, the people it put us next to, the habit of treating Estonia as where we are from rather than where we are registered. It is a small country that takes its startups seriously, and a young company gets further into the room there than it would in most places. ## The Headaches and the Eclipse I dealt with severe headaches over the past few weeks. Not the kind you work through. I could not focus on working with Claude or hold the sessions I had running, and after a few attempts I stopped trying. Calls were the exception. I could talk to people all day and do it well, then sit down in front of something that needed building with nothing to bring to it. When I journaled about it at the time I put it down to overwork. I had been running too many sessions at once and they were asking more of me than I had. The explanation was sitting right there and I took it. Then the headaches intensified on the morning of the eclipse, and I realised this was probably solar. The eclipse itself. I have since read that there were big flares and other activity across the same days that may have played a part. I did not go far down that road. I took it as a sign to slow down, pay attention, and enjoy the intensity of the energies and what was to come. In the evening we went down to Scheveningen to watch it go. The full shadow was somewhere else, up over Iceland and northern Spain, so what reached our stretch of coast was partial. It was still the strangest light I have seen. I felt the temperature shift, and there was this rare intensity over the sea, the shore and the skyline. And I noticed the headaches leaving. ## Two Meetings on the Monday Through all of this the Estonian grant had come back asking for additions. I had a good feeling about that one. They would have stopped it long before if it was not going to fall our way. Then on the Monday morning right after the eclipse I was rushed into two meetings back to back. The first, with Turku University of Applied Sciences and RISE in Sweden, I had not properly registered. I came into it late and off guard, expecting to find out whether the idea had legs. Instead they told me they were very interested in the proposal I had written, and that they saw a real opportunity to form a consortium and apply to a specific Horizon call. The money is the smaller part of what that means. A consortium puts the development into institutions that already have the people to do it, which is a very beneficial way for us to resource this. It also builds our network and our expertise inside the Nordics, one of the most advanced cybersecurity regions in the world. I would rather be building inside that than watching it from across the water. The meeting straight after was with the compliance manager at Qwello. Two of our agents already run on their Dutch branch, the cybersecurity one and the contract management one. We came out of it with a verbal agreement to look at scaling those to the whole group, so that everybody can reach them in Slack rather than one branch having them to itself. That is seven member states and a step across Europe in one move, out of a single conversation, with nothing new to build. ## All the Pieces Clicking Together The Estonian grant landed still inside two weeks of the eclipse, and that is what showed me the roadmap unfolding, with all the pieces literally clicking together right after it. It shows itself like this. The Estonian grant establishes us further into the Nordic ecosystem and shows that we are a good subsidy partner, which builds our track record around these things. It also buys us a year of research and development with an institute as good as TalTech. In parallel we work with RISE and Turku to develop the proposal for the Horizon call, which we submit around November next year. If that works out it is a budget of one and a half million euros. Small for a Horizon call and for institutes of that size. Very big and very impactful for us as a young startup. Qwello runs through all of it. Their expansion gives us a European-wide client base we can use across the research, which is a great spine for the whole thing to sit on. It will also give us a lot of credibility for winning clients elsewhere in Europe. Three pieces, and each one makes the next easier to argue for. ## Knowing Where to Look That roadmap came together right after these intense eclipse energies, and the eclipse clearly had a European theme to it. Its shadow ran the length of the continent. When you know how to pay attention to the right things, you can see these things coming. I was alluding to this event four months ago, writing about it in these entries, and I can hold what I wrote back then against what has landed now. Never knowing, of course, exactly how it was going to fall together. But being confirmed again. This is the way that it works, as far as I can tell, and learning the specifics of it each time is still a beautiful surprise. It helps me believe that we are on the right track, and it lets me watch these things arrive synchronistically rather than by force. It runs all the way back to the beginning of this one. The meeting with Tiia in the accelerator programme is where the proposal came from in the first place, and all of that has now come together in this converging moment of the eclipse. Which is exactly why I get so excited about journaling about it in this way, where I can share it and show it to people. With care, Ben --- # When Running More Agents Stops Making You Faster URL: https://blog.askara.solutions/source-journal/Entry-40-When-Running-More-Agents-Stops-Making-You-Faster Category: source-journal Author: Ben Visser Date: 2026-08-10T00:00:00.000Z Hey there, My productivity started going backwards three sessions before I noticed. I did not know that at the time. What I knew was that July had gone well. I had my hands back in the work after a long stretch of not, and everything moved faster with me inside it rather than beside it. So I ran more. Several sessions at once on different parts of the agent fleet, and I moved between them while they worked. Then the plans started getting longer. Ask for a piece of work and what comes back for approval is a bigger document than it was a month before. More steps, more files touched, more time to produce and more of my time to read before anything could start. Six of those running at once and most of my attention was going on holding in my head what each session thought it was doing. Some weeks I lost the thread entirely and had to go and reconstruct it. By the back half of the month I was tidying up after myself more than I was building. A few days ago I stopped mid-afternoon with nothing left to think with and took the rest of the day off, which I do not often do. Two suspicions came out of that, and I went after the wrong one first. ## The Suspicion I Started With The plans getting longer is what made me think about money. These tools are paid for by the token, and a longer plan is a longer bill before a line of it gets built. They also have a reliable habit of handing you more than you asked for. Extra dependencies, structure for a case that will not arise, two hundred lines where fifty would have done. So I wondered whether the over-delivery was less a flaw in the machine than a feature of the business. There is real work on this. A paper from the spring shows that the tokenisation of a piece of text is not unique. You only ever see the count the provider reports, so a provider's return is tied to the length of the sequence it chooses to report. Checking it is NP-hard, which puts verification out of your reach at any sensible price. The authors also prove that pricing on characters instead of tokens removes the incentive, and that a provider could switch while holding its margin. The fix exists, it is published, and nobody has taken it up. I am glad I looked, and I am leaving it there. It says nothing about anyone's conduct. The bill I paid in July was not denominated in tokens. ## Three Is the Number The other suspicion was the one worth having. Longer plans did not only cost more to produce. They cost more to hold, and holding them was my job. That has a name and a literature. Boston Consulting Group, with researchers at UC Riverside, surveyed just under fifteen hundred workers and called it AI brain fry: mental fatigue from the use, interaction with and oversight of AI tools beyond what a person can carry. Fourteen per cent of workers using AI report it outright. The ones who have it show a third more decision fatigue and thirty-nine per cent more major errors. A third of them are thinking about leaving their jobs. Two findings rearranged how I read my own month. Productivity gains plateau after about three simultaneous AI tools and then go backwards. Not level off. Go backwards. I was running six and congratulating myself on the throughput. Three is not a fixed ceiling either. It assumes some weight per session, and as the plans grew each session got heavier, so my real ceiling was coming down while my count went up. The second finding is the one that makes this causal rather than atmospheric. Where AI replaced routine work, burnout scores fell by fifteen per cent. The damage does not come from the AI. It comes from supervising it. The machine has the same curve. Anthropic call it context rot. Put more into a context window and the model's ability to recall from it accurately drops, so a bigger context is not just dearer, it is worse. Two substrates, one shape. Past a certain load both the person and the model stop improving and start degrading. In both cases the fix is the same. Keep the working set small and let structure hold the rest. ## Building the Limit Into the Tooling That changes what our harness is for. We had been hardening it so the machine follows the discipline: git hooks that run whether or not anyone remembers them, coverage gates that measure what the tests reach rather than asking the work to mark its own homework. The harness has a second job I had not been giving it. It has to protect the person supervising it. Both jobs want the same controls, which is how I know they are the right ones. The largest lever is what gets read. Agents spend about seventy per cent of their token budget working out where things are rather than answering the question, so scoping the reading beats compressing anything afterwards. Fetch by path when the work needs it instead of loading the world up front. Give a specialist a clean context, let it do the exploring, and have it hand back a page instead of a transcript. That one does double duty, because a page is also what I can read without emptying myself out. The way we already hold our library, one core with everything pointing at it and nothing copied, turns out to have been a token optimisation the whole time. We built it for tidiness. Then the gate. Make the agent produce a read-only plan before it writes anything, above some threshold of files touched, and approve the plan instead of the diff. Planned work lands in roughly a third of the time that code-then-discover-then-undo takes. What I approve is a paragraph instead of a sprawl. And the plan gets a size limit, which is the part I would have missed a month ago. If what comes back cannot be read in a few minutes then the work is too big and wants splitting, and a plan is a much cheaper place to find that out than a diff. And the plateau becomes a setting. Three concurrent sessions, because that is where the curve turns, enforced by the tooling rather than by my judgement at four in the afternoon, when my judgement is worst. None of which I can tune without measuring it. We already log what our agents decide and where they get blocked, because an auditor will want to see it. That log is also the only honest view I have of my own consumption, session by session, and the only way to find out which of these controls earns its keep. A record built to satisfy somebody else turns out to be the instrument I need for correcting myself. ## A Control That Weakens Under Load This is not a note about working habits, and here is why. We build AI agents for cybersecurity compliance. What we tell clients is that human behaviour belongs inside risk management rather than beside it. That argument has just arrived with an effect size attached. An operator supervising more agents than they can hold makes thirty-nine per cent more serious mistakes. In our line of work a serious mistake is a misconfigured control, a risk left untreated, an incident nobody logged. Look at the structure and it is worse than an ordinary human factor. The control is human review. The load on that control is the volume of AI output. So the more you deploy, the more review you need, and review is the thing that fails as volume rises. The control degrades as a function of the thing it controls. Anywhere else we would call that unacceptable and design it out. I have not seen it in a single risk register. So it goes in ours, and it goes into what we build. Not as a wellbeing initiative. As a control with a threshold, an owner, and something that trips when it is breached, the same as any other. I do not know yet how much of the load will move. Some of it plainly will. Whether the work in front of me is the right work is not checkable by a hook, and that was the part that emptied me out. There is also a version of this where I build a better harness and then run more sessions through it, arriving back at the same afternoon by a longer road. That is the one I want to be watching for. With care, Ben --- # What Sunflowers Teach Us About Building AI Agents URL: https://blog.askara.solutions/source-journal/Entry-39-What-Sunflowers-Teach-Us-About-Building-AI-Agents Category: source-journal Author: Ben Visser Date: 2026-07-29T00:00:00.000Z Hey there, Last time I wrote about having my hands back in the work, building our agents myself instead of handing the job down, and about how an AI gives you your own way of working back. This carries on from that, but it is about the shape of the thing rather than the tone of it. Something changed for me this week. I started using Claude Code on my phone. So now I walk, and I talk to it, and it builds. The dog gets me out several times a day anyway, and we moved recently so there is a lot of nature around the house. Walking in nature really does help me think better. What is new is that I can act on the thinking out there, instead of carrying it home. A thought that turns up two kilometres from a desk has to survive the walk back, and most of them do not. Now they do not have to. ## A Short Walk After the Painting Class Last night I had my painting class. It is not a class where somebody teaches you from the front. It is an open workshop, so you bring what you are working on and get on with it. I spent the last few sessions reading up on the golden spiral and the Fibonacci sequence, which is my own interest rather than anything on a syllabus. They are one thing seen from two sides. Every number in the sequence is the sum of the two before it, and drawn out, that proportion gives you the spiral. It sits in a shell, in a pine cone, in the seed head of a sunflower, and in the way a lot of the paintings I love are laid out. I want to work that beauty into my own paintings deliberately, so I was learning how it is done. Afterwards I took the dog out, which is when these things truly start to sink in. What I was turning over was not only the paintings. The other thing I make is software. We build AI agents that do the slow work of cybersecurity compliance, and underneath them there is a library of skills and reference documents that tells each agent what the work actually demands. I wanted to know how I could work the same beauty into that on purpose. So I started looking at the library, out loud, while the dog got on with the walk. ## Why the Shape Is There So I had gone out wanting to put something in, and found it already there. Our library is arranged in a way nobody designed on purpose, which leaves the better question. Why is it there? The answer is a limit. A model can only hold so much at once, so the knowledge has to be packed to give the most clarity per word it carries. Which is the same problem a sunflower has, and here my evening came back round to me. A seed head has a fixed area and a great many seeds, and every one needs light. The flower solves it with the exact thing I had been reading about. Each seed goes in at the golden angle, which comes out of the same proportion as the spiral I had been drawing, and if you count the spirals in a seed head you get Fibonacci numbers. None of it is approximate. It is precise, and it is the best packing of a fixed space there is. We did not borrow that from the flower. We came up against a hard limit and were handed a design that was already sitting in it. I am not going to pretend I read that as coincidence. I think the design was there first. The sunflower did not invent it and we certainly did not. It holds whether you are packing seeds into a flower head or knowledge into a machine. The limit is not what makes the shape. The limit is what makes you look until you find it. ## One Rule at Every Size We keep a style guide for how all of that gets built, and it opens with three principles I have read many times. Every piece of knowledge lives in one place, and everything else points at it instead of repeating it. Nothing gets loaded into an agent's attention until a decision needs it. Each file has one job. On the walk those three stopped being three. They are one rule said at different sizes. There is one core that holds the truth. There is one thing above it that hands out only what the next decision needs. And around those sit the smaller pieces, which point back at the core and never copy it. I checked it at every size and it held: the whole repository, then a single plugin with one gateway skill that everything else goes through, then a skill, down to one reference document with a short summary at the top telling you whether to read the rest. That is not tidiness. It is why a change only has to happen in one place, and why an agent can read a hundred words to make a decision instead of ten thousand. Once you can see the design you can work with it instead of arriving at it by accident. So we wrote down what the flower is doing, and those same three principles came back as three things we now check. The first is placement. The golden angle puts each new seed where it shadows none of the ones already there. Most coverage, least overlap, under scarce light. Ours works the same way. Before a new skill goes in, we look at what the existing ones cover and put the new one where the overlap is smallest. If it overlaps too much it does not become a new skill at all. It gets merged into the one it was overlapping. That takes a principle everybody nods at and makes it something you can actually check in a review. The second is that anything new gets built out of what is already there. A new capability has to name the one or two existing ones it is the sum of. Our supplier exit planning came straight out of the continuity work and the risk quantification work already in the library. If something cannot name any parents, it is usually too early. The third is my favourite, because it is about the person reading. They should only have to open one new layer to make one decision. If a decision needs three documents open at once, the structure is knotted and we flatten it. ## What We Keep Finding Months ago I came home from a concert hall and [wrote about that evening here](/source-journal/Entry-10-Leveling-Up-Our-Vision). The programme was about Gödel, Escher, Bach, and what had caught me was the idea of systems that watch themselves work. Not software that follows rules, but software with a layer above it asking whether the rules are catching the right things, and another above that deciding which changes are safe to make. Systems that get better at getting better, and that pull themselves back into true when something has drifted. I wrote then that it was a long way off. It was. We keep finding that pattern one place at a time, and every time it turns out to have been waiting there already. We are being shown where things were always meant to fit. There is a practical reason this landed when it did. The last three weeks of the cycle have been the most productive stretch of work I have ever had. I have built something like ninety per cent of the agents our product needs, so there is a fleet of them now, and the question in front of me was how they all fit together. A few weeks earlier this would have been an interesting observation and little else. So the first thing I did with the rules was take them back through everything we had already built. Months of older material, a good deal of it written twice in slightly different words. I pruned it against the three rules, merged what overlapped, moved what was sitting in the wrong corner. It works because nothing was ever duplicated, so the whole library can be brought back into true without breaking what depends on it. What was a pile of separate agents is one orchestration now, and I am genuinely impressed by what came out the other side. That much was directed. Me, rules in hand, going through it myself. But we have since built the checking into the system that holds all of this, so it measures its own structure against these rules and repairs what has slipped without me walking through it. That is not the whole of what I was carrying out of that concert hall. It is one step towards it. Not the product watching itself work, which is where I had been looking. The knowledge underneath it, watching its own shape. It runs on the same beauty those three were each working with in their own art, a proof, a drawing, a piece of music, and it reached me through mine. A few evenings with a spiral I wanted to paint, and a walk I would have taken anyway, with the phone in my pocket. With care, Ben --- # Am I Trying to Hit This, or Understand It? URL: https://blog.askara.solutions/articles/Am-I-Trying-to-Hit-This-or-Understand-It Category: articles Author: Ben Visser Date: 2026-07-24T00:00:00.000Z Ninety-five per cent of staff completed their security training. It is the kind of number that ends a conversation. It looks like proof, it fits on a slide, and nobody in the room wants to be the one to poke at good news. It also tells you almost nothing. Not whether anyone learned anything. Not whether a single person would spot a real attack on a bad day. It measures that people clicked to the end of something. And yet it sits in register after register, dressed up as a key performance indicator and defended with a green dot. The question I keep coming back to, and I am still working out the full answer, is why we write numbers like that down and call it measurement. ## Goodhart Is a Property of Targets, Not of People You have probably met Goodhart's Law, even if not by name: when a measure becomes a target, it stops being a good measure. It usually gets told as a story about people. Set a target, and people optimise for the number instead of the thing behind it. The sales team games the call quota while the relationships rot. Staff [click through the training](https://blog.askara.solutions/journal/The-Training-That-Nobody-Remembers) while nobody learns anything. Told that way, it sounds like a warning about human nature, and it pushes you toward a particular response: watch people more closely, add more checks, assume they will cut corners and design to catch them. That instinct is where a great deal of compliance quietly curdles into distrust. But I think it misreads the law. The gaming is not the cause, it is the symptom. Goodhart only bites once you have decided that a measure is a target: something to be hit, cleared, reported green. The behaviour everyone frets about comes after a much earlier and much more casual decision, the decision to point a commitment at a number in the first place. That is the shift that changed how I read it. Goodhart is not really a fact about people being weak. It is a fact about what targets do. So the place to deal with it is not people's behaviour. It is the choice of what becomes a target at all. ## Signal, Target, and Noise Before you decide whether something should be a target, decide whether it is worth measuring at all. Nate Silver's *The Signal and the Noise* is useful here. Most of what we collect is noise: numbers that are easy to gather and comforting to look at, and that carry almost no information about the real state of things. The signal, the reading that would actually change a decision, is rarer, harder to see, and usually buried under a heap of green dots. A register is where noise goes to hide. Completion rates, ticket counts, percentages on track: most of it measures activity that is easy to count rather than outcomes that are hard to know. And the worst thing you can do with a noisy number is make it a target, because now you are committed to hitting a figure that meant nothing to begin with. Ninety-five per cent completion is the specimen: noise, promoted to a target, defended on a dashboard. Sort an honest register and you find three things, not one. There is noise, which should simply be deleted. There are targets, real commitments you intend to hit, which are legitimate but gameable by nature, so you keep them few and choose them carefully. And there are signals, readings you are trying to understand rather than scores you are trying to beat. Almost every register I have seen treats all three the same, and quietly defaults the lot to targets, because a target is the only shape the form knows how to hold. ## The Target Test Here is the discipline I have landed on, at least for now, small enough to use this afternoon. For each measure, ask one question: am I trying to hit this, or understand it? If you are trying to hit it, it is a target. Keep it, but sparingly, because every target is a fresh surface for Goodhart to work on. And be honest: if you would do nothing differently on missing it, it is not a target, it is noise, and it can go. If you are trying to understand it, it is a signal, and it should not be scored. Write it as a question, not a threshold: "Do people recognise a phishing attempt when they are busy and stressed?" rather than "ninety-five per cent completion". Track a reading and a direction of travel, not a pass or a fail. Attach a target to a signal and you have turned the thing you wanted to understand into one more number to optimise, with a green dot to reassure you the whole way down. If you are unsure which one you are holding, there is a quick check. Ask: could I hit this number while the reality under it got worse? If the answer is yes, it was never a target. It is a signal in a target's clothes, and it will lie to you in the most convincing way there is, quietly and on schedule. None of this needs software. The sorting is something you can do with a pen. But it is also a design principle for the tools that hold a management system, and most of them know how to hold only targets, which is why [understanding keeps getting flattened into a score](https://blog.askara.solutions/journal/Measuring-What-Matters) the moment it is typed in. Some of what we are working on at Askara Solutions is simply letting a measure stay what it is, a commitment to hit or a signal to read, so the distinction survives contact with the system. The thinking comes first, though. The tool only ever inherits it. ## It Is Not One or the Other I should be honest about how I got here, because I did not start with a tidy rule. When I began pulling this apart, I was fairly sure the answer was that most of these numbers should have been signals all along, and that targets were the villain. Writing it through changed my mind. That is the same mistake stood on its head. A register with no targets in it is not more honest, it is just directionless. Some things genuinely are commitments, and a commitment has every right to a threshold and a red mark when you miss it. What I actually landed on, somewhere between the first draft and this one, is that it was never a choice between the two. A healthy register holds both, deliberately. The problem was never that we had targets. It was that we had only targets, because nobody chose; the form chose for us. So the skill is not picking a side. It is staying awake to which kind you are holding, and refusing to let the default answer a question you never noticed you were being asked. ## The Decision Nobody Debates Come back to that ninety-five per cent. Nothing about the number has changed. What changes is that you can now see what it is: a noisy figure that someone, at some point, waved through as a target. Not because the staff clicking through the training were weak, and not because whoever wrote the module did a bad job, but because turning things into targets is the path of least resistance, and no one paused to ask whether this one had earned it. Goodhart's Law was never really a warning about people gaming the system. It was a warning to whoever builds the system, about the numbers they choose to chase. You do not answer it by pushing people harder. You answer it, I think, by being a little more reluctant about what you ever agree to hit, and a little more curious about what you would rather simply understand. --- # The Structure the Machines Do Not Know They Want URL: https://blog.askara.solutions/articles/The-Structure-the-Machines-Do-Not-Know-They-Want Category: articles Author: Ben Visser Date: 2026-07-24T00:00:00.000Z There is a question a good management system ought to answer in seconds. If this one risk changed tomorrow, which objectives would it touch, which measures would need rethinking, which controls suddenly matter more? It is not an exotic question. It is close to the whole point of having a management system. And it is exactly the sort of question you would expect an AI to be brilliant at: joining the dots across everything you hold, instantly. So it is worth understanding why, today, it would not be. Point a capable model at a typical management system and the thread it needs, from that risk to the objectives to the controls, is not actually in the data. The relationships are implied, scattered across columns in separate registers. So the model does the only thing it can. It hauls whole tables into its context, tries to reconstruct the connections on the fly, makes several passes, burns a startling number of tokens, and keeps you waiting. Then it returns something confident, fluent, and quietly incomplete, because somewhere in the reconstruction it inferred a link that was not there and missed one that was. That is not the model being weak. It is the model being handed the wrong shape. And I have been sitting with a suspicion that the shape is about to change, and not in a small way. ## From Filing to Reasoning So what is the right shape? A management system is not really a set of registers. It is a web of relationships. An objective exists to serve an aim. A measure exists to tell you something about an objective. A control exists because a risk justifies it. A change exists to move one of them along. The value lives in those connections, and a stack of tables is precisely the shape that throws them away, keeping the rows and discarding the lines between them. That is why anything reasoning across the whole thing, you or a model, has to rebuild the web before it can use it. When the connections are kept instead, when the whole chain is held as connected knowledge, something shifts that is hard to overstate until you have felt it. That expensive, half-blind reconstruction simply does not need to happen. "What does this risk touch?" stops being a scavenger hunt and becomes a walk along relationships that were there all along. It is faster, it is cheaper, and, the part that matters most, it is complete. And the context compounds: every connection you add makes the next answer richer, because the structure itself is generative. A table sits there. A connected structure gets more useful the more of your world it holds. That is the tangible shift, and it has almost nothing to do with databases. It is the difference between a management system you maintain and one you can reason with. ## Trained on the Old Filing System Here is where it gets strange, in a way I find genuinely funny. This connected structure is not only better for humans. It is the shape an AI reasons over best. Give a model a defined web of things and relationships and it can traverse it, follow the implications, and answer the question you actually asked. Give it a pile of loosely related tables and it does roughly what we do: reads the one in front of it and guesses at the rest. And yet today's models are, if anything, worse at the better shape. They were raised on the old filing system. The overwhelming majority of what they learned to write is SQL, the query language of relational tables, so that is what they are fluent in. The languages that walk a graph of relationships are comparatively rare in their training, so they handle them more clumsily. The substrate that would serve an AI best is the one it is least practised at. It would suit the machines beautifully. They just do not quite know it yet. I think that gap closes, and closes quickly, because the pull is structural rather than fashionable. But it is a real paradox worth naming: for a while, the AI-native way to model your governance will feel like the road less travelled, precisely because the AI was trained on the road everyone else took. ## How Serious AI Already Gets Built If that sounds speculative, look at where reliability actually matters most. The teams building AI that has to be dependable, where a confidently wrong answer is not an amusing screenshot but a genuine problem, have largely converged on the same move. They do not point a model at raw data and hope. They ground it in an ontology: a defined model of the entities in their world, the relationships between them, and the actions that can be taken on them. Palantir is the best-known example, and it has built much of its platform on precisely this idea. The model does not reason over tables. It reasons over a map of what things are and how they connect, and that grounding is what makes the output reliable enough to act on rather than merely interesting. Read that back with compliance in mind and the fit is almost uncanny. A management system is [already an ontology waiting to be written down](https://blog.askara.solutions/journal/GRC-Based-on-AI-First-Principles): aims, objectives, measures, controls, risks, and the relationships that bind them into a whole. We have simply been storing it in a shape that hides the relationships rather than one that makes them the point. The move that makes serious AI dependable is the same move that makes a management system something you can reason with, and I do not think that is a coincidence. It is where we find ourselves being pulled at Askara Solutions, and we are still working out how far it goes. ## The Filing Cabinet Was Never the Point For thirty years the goal was a tidy record: everything filed, everything findable, ready for the auditor. That was the best a management system could be when the connections could only live in someone's head, or in a diagram nobody kept up to date. It was never really what anyone wanted. What you want from a management system is to be able to think with it: to ask a hard question about your own organisation and get an answer that holds the whole picture at once. That was impossible to build and expensive to fake, so we settled for the filing cabinet and called it governance. We may not have to settle much longer. The interesting question is no longer how to store what you did. It is what you will finally be able to ask. --- # The Work Comes Back as a Mirror of Whoever Made It URL: https://blog.askara.solutions/source-journal/Entry-38-The-Work-Comes-Back-as-a-Mirror-of-Whoever-Made-It Category: source-journal Author: Ben Visser Date: 2026-07-22T00:00:00.000Z Hey there, Wednesday morning is the one I keep. The rest of the week fills the way weeks do. But Wednesday I block out and sit down properly, the week's notes in front of me, to look at what actually happened. Small realisations turn up all week, always in the middle of something, and in the middle of something there is never room to stop with them. So they wait. Wednesday is where I finally stop for them. I want to be plain about how that stopping happens now, because it matters to the whole of what I want to say. I do it in conversation now, thinking out loud with an AI, my notes beside me. The looking gets sharper as we talk. A year ago that sentence would have embarrassed me to write. It doesn't now, and understanding why is more or less the entry. ## What the Clearing Gave Back For months I had a small pile of heavy decisions sitting open at the back of my mind. The largest was whether to take outside money into the company. Over these past weeks they settled, one by one, until the pile was gone. I did not expect how much room that would leave. With the questions answered, I have had whole days with nothing pulling at my attention, and I have spent them building. That is the part worth being honest about. We build AI agents, software that does the slow work of cybersecurity compliance. This last stretch I have been building ours myself, directly, hands in it. Not scoping it and handing it down. Sitting with the work and making it, one long stretch after another, the kind of day where you look up and the afternoon has gone. I have not worked like that in a long time. It took the clearing to see how much I had missed it, and how much faster the thing goes when I am inside it rather than beside it. ## Two Sets of Hands Building this way taught me the plain thing first. You treat the AI as an employee, not a tool. Not something you operate and tidy up after, but something that will do the work, all of it, if you can say clearly enough what the work is. The whole skill is in the communicating. And that is why an older instinct quietly broke. I used to hand the task to someone who would then instruct the AI for me. I am the one who holds what our compliance work demands, and what an auditor would need in order to trust it. Pass that through another person on its way to being built and you stack two rounds of instruction on top of each other. What I hold gets a little thinner at each step, a little truth lost in translation twice over. No failing of anyone's, just one retelling more than the work could bear. At first, doing it myself was only me stopping that leak. But doing it myself set up the thing I actually want to write down. I could only see it once the work was in my own hands. I put the agents I had built next to ones a colleague had built for the same product. We had aimed at more or less the same thing. They had come out completely different. Not one right and one wrong. I want to be careful to say that, because a comparison is easy to mistake for a verdict, and this is not one. Mine had come out as guides. They want to ask you where to begin, they lead with a warmth you can hear, they worry about meaning and about not taking a number for the truth behind it. His had come out closer to machines, deciding the route before anything else, exact and precise, careful with every record they touch. Both are good. Both are needed. Each is strongest in exactly the place the other is lightest. Seeing them side by side showed me something I had missed entirely. The AI does not only take your instructions. It takes your whole way of working and hands it back to you, larger. Everything I make carries my instinct to guide, to lead with warmth, to ask before deciding. Everything he makes carries his. The same task, given to two people, comes back as two different pieces of work. The work is partly a mirror of the person who made it. Once I had seen it I could not unsee it. Getting something good out of this is not about learning the tricks of how to ask. It is about knowing what you are, because whatever you are is what comes back to you. And that is not a thing anyone can tell you from the outside. It shows up only once you have had your hands in the work long enough to watch yourself appear in it. ## The Time It Took to Learn I want to be careful how I tell the year and a half before this. The easy version is that we were falling short and have finally got it right. That is neither true nor fair. We needed that time. Every month of it. There was a whole craft to learn that no one could hand us ready-made. How to work with these tools, how to keep the code in good order. Where the old way of stitching systems together still helped, and where it only got in the way. How to build on a technology that kept changing under our feet as it grew more capable. The early scaffolding we built taught us the ground even as we outgrew it. Enough has come together now that we can drop a great deal of it and go straight at the thing. But we could only drop it because we had built it first, and learned what it was standing in for. The deeper lesson took just as long, and could not have come sooner. That you treat the AI as an employee. That what you are is what it hands back. None of it is something anyone can talk you into believing. I had read the words. I could have said them all at the beginning and not understood a thing I was saying. It arrives only after enough hours with your hands in the work. Enough that came back wrong because you were vague, enough that came back right because you were clear, until it becomes something you know, not something you were told. So there is no regret in any of it. I keep checking myself on that, because I distrust the story that calls every slow stretch secretly essential after the fact. But this one holds up. Take those months away and I would be standing here now with all the room to build and none of the understanding to build well. What I notice, sitting here on a Wednesday with the afternoon ahead of me, is not that I have arrived anywhere. It is that the work keeps handing me things I could never have been told, and this one, that whatever I am is what comes back to me, is only the latest. A year ago it would have been something else. A year from now it will be something else again, something I cannot reach for yet, because I have not put in the hours that would let me hold it. Where that goes I don't know. And the plainest pleasure of it is this. Even sitting down to understand my own week, I now do the same as everything else that is working: clearly, out loud, with something that meets me and hands back whatever I bring. With care, Ben --- # How a Small Team Quietly Finds Its Own Shape URL: https://blog.askara.solutions/source-journal/Entry-37-How-a-Small-Team-Quietly-Finds-Its-Own-Shape Category: source-journal Author: Ben Visser Date: 2026-07-09T00:00:00.000Z Hey there, Last week I signed off on the small, half-built thing on the bench, and the people gathered around it. That was the point, I said. Not the taller buildings, not being wanted. Since then it is the gathering itself that has held my attention. The solstice light has been easing back down these last weeks, and in that softening a shape came into view. Something we had been carrying for months without looking at it straight. I should be honest: we don't spend our days deliberately tuning into these things. Most of the time the current just carries us, the way it carries anyone. It is the pause that changes that. Sitting down to write like this is what lets me step out of the water for a moment and notice what has been forming while we weren't looking. ## What the Long Light Made Room For We had given this cool-down four weeks rather than the usual two, and by the end of the week it has done its work. We re-read the goals we set for the second half of the year. Where they had drifted from the season we are actually in, we let them settle somewhere truer. The goals moved, so the way we carry them had to move as well. We looked again at who holds what, and shifted the weight until it sat more evenly. And we talked about money more plainly than we ever have. How long the runway really is. How each of us carries the risk of it. That kind of conversation stays uncomfortable right up until the moment it turns into relief. None of that is what I want to write about, though. None of it was really the heart of it. It was closer to the housekeeping a change of season asks for. What I keep turning over is something that surfaced alongside the work, almost underneath it. Somewhere in the re-reading and the rebalancing, the way we actually work together rose to the surface. We had been half-referring to it for months without ever looking at it straight. ## The Shape Simon Gave Us It isn't mine, and I want to be careful to say so. It came from Simon, months ago. A simple way of describing the company as a triangle, with the three things it takes to build what we build at its points. It has been a quiet reference between us ever since, the sort of shorthand a team leans on without noticing it has turned load-bearing. What changed recently was small, and obvious once you saw it. The triangle grew a fourth point, in the middle. At the three outer points sit the things the work can't do without. Andrew holds the technology, the actual building of the thing. I hold the subject matter: what compliance really demands, and what someone inspecting our work would need in order to trust it. Simon holds the customer experience, and more than that the community we are building this for. Each of us is what we have started calling the source of our corner. Not the name against the task, but the one the work of it genuinely comes from and returns to. None of this means a corner rests in one pair of hands. The building especially is a team, not a person. Andrew anchors it, but others build alongside him, tagging in and out as the work moves. And the triangle only ever described one part of the company, the part where the product gets made. Around it runs work it doesn't touch at all: the partnerships and the funding that quietly buy the rest of us room to build. The fourth point, the new one, is Zach. What sits with him is the prototype itself, the half-built thing on the bench. He takes what the three of us hold and shapes it into the next real version of the product. That centre is where the surprise turned out to be. ## What Passes Between Us A shape like this is only worth anything for what moves between its points. Between Simon and me it moves both ways. I tell him what has to be true for the thing to be trustworthy. He tells me what the people using it are struggling with and hoping for. Somewhere between those two truths we have to meet. But here is what struck me once I looked properly. Very little of the rest runs point to point around the outside. Almost all of it runs inward, to Zach in the middle, and then back out. We each hand Zach what we know. I give him what a good and honest result has to look like. Simon gives him what the community needs. Zach takes both. In a way of working entirely his own, he turns them into a clear account of what to build next. That account, and only that account, goes to Andrew. Andrew builds it, and what he learns in the building comes back to Zach. Then the finished thing goes out to all of us at once. To Simon, for the community. To me, to check it still holds to the standard we set. Seeing it whole corrected something I had backwards. I had assumed Andrew was the one carrying the tension between what I needed and what Simon needed, forever balancing the two of us. He isn't, and he shouldn't be. That balancing had moved to Zach, who is far better placed to hold it, because holding exactly that is what his kind of design work is. Andrew takes his instructions from one place and reports his results to everyone. That makes his corner not smaller but cleaner. He gets to build, freed from a negotiation that was never really his. ## The Rivers Don't Rise on Their Own I want to resist the version where all of this simply arranged itself and I had the good sense to stay out of the way. It is the story a person like me is supposed to tell. All stepping back and trusting the process. And it would flatter the part of me that has spent a lot of these pages learning to do less. But it isn't what happened. Telling it that way would quietly write me out of my own company. The truth is less humble, and I have decided to just say it. I was necessary. The seeing was necessary. Being the one who can look at people at work and make out the shape they are standing in is a real part of what I am for. Pretending otherwise is its own kind of vanity, the sort that hides behind modesty. I know it from how the weeks actually went. In that meeting after China I saw the spark catch, and I assumed that because I had seen it, everyone had. What followed didn't bear that out. The ownership I thought had lit wasn't showing up yet in what people did from one day to the next. It took me coming back to it, more than once, naming it again and cementing it, before it began to hold. Not because the team is slow. Because a thing one person sees clearly is not shared just by being true. It has to be shown, and shown again. I have written before about staying low, the sea beneath everything so the rivers find their own way down to it. I think I only had half of it. The rivers do run down, and gathering what they carry is real work. But water that only pools at the bottom is the end of a story, not a cycle. The half I keep underestimating is the rising. Something has to lift what has gathered back to the top, so it can fall again as rain. That lifting is the seeing and the shaping. You take the raw thing that has come down, everything the team has made and felt and half-noticed, and turn it into something clear enough to send back round. Then it flows through all of us again instead of settling into the mud. This is the part that is mine. Catching what came down these weeks, and folding it into something clear enough to hand back up. So that is what I will carry out of the long light. Not a decision. Not the comfortable idea that the company runs itself. A way of seeing us that I mean to carry to the others, knowing now that saying it once will not be enough. I will have to keep seeing it and saying it until it holds. All of us gathered around one small, half-built thing on a bench. Some anchoring its corners, others holding the work that keeps it fed. Everything we know flowing to the middle, and back, and then, if I do my part, up and round again. With care, Ben --- # Being Wanted, and Getting Real URL: https://blog.askara.solutions/source-journal/Entry-36-Being-Wanted-and-Getting-Real Category: source-journal Author: Ben Visser Date: 2026-07-02T00:00:00.000Z Hey there, A few weeks ago, a fund approached us. I haven't put it that plainly until now. If you've been reading these entries you'll have caught me circling something I wouldn't name, a conversation that arrived from a direction I wasn't watching, a pull I kept gesturing at and then stepping around. That was this. There were obvious reasons to keep it vague while it was live, and I'm still not going to say who they are or pretend it got further than it did. But it's settled enough now that I can be straight about what happened, and, more usefully, about what it did to me, because that turned out to be the actual story. What it did first was flatter me. And then it sat me down in front of a test I'd set myself not long ago, back when I was untangling my old flat refusal of outside money and admitting that some of the no was principle and some of it was just me looking away. The test I wrote down then was simple enough: could I feel the pull toward the exciting thing and choose, deliberately, not to move on it. Here it was. The pull, in the flesh. So I did the only thing I trust with something this loaded. I brought it here, to these pages, and turned it over week after week. What I noticed first was that reason had very little to do with my reaction. What pulled me toward yes was reflex: the old money-greedy part of me and the plain flattery of being wanted, the same part I'd spent an earlier entry pulling out of the shadow and admitting was mine. The gift of the approach was that I got to watch that reflex fire for real, and see what it actually did to me. And that was what sent me back to the flat no I used to hold, not to hide in it again, but to set it beside the pull and look at both of them honestly. The work was never the deciding. It was keeping both in view, the pull toward yes and the old refusal, so that neither could quietly make the choice for me. I'm writing it this way on purpose. The fund, the flattery, the decision, those are only the surface. What I actually want to hand you is the thing underneath: the slow work of looking, which I've come to trust more than almost anything else I do. Most of the choices that shape a company get made by reflexes nobody stopped to examine. This is me stopping to examine one, out loud, while it was still live. If anything here is worth your time, I suspect it's less whatever I conclude than the plain evidence that stopping to look at all changes what you choose. ## Being Wanted There's a particular warmth to being noticed, and I'd be lying if I dressed the last stretch up as sober from the start. Someone looked at what we're building and paid real attention. We didn't go knocking, the interest found us, and being sought does something to you. It whispers that you're onto something, that the years of unglamorous work are visible from the outside after all, that you matter in the room. I let myself feel every bit of that. And here's the honest part: nothing concrete was ever on the table. We never got far into anything, no offer, no number, nothing I could actually point to. It was a door opening, an early signal, no more, and I sat in it a good deal longer than its real weight deserved, turning the flattery over in my hands and enjoying being taken seriously. There's no dignity in pretending otherwise, and I've come to think it's healthier to name the vanity out loud than to perform being above it. So, yes. It felt good to be wanted, even on the strength of not very much, and I'm not going to apologise for having liked it. And then, once I'd had my fill of that, it was time to get real. Because the warmth of being noticed is a feeling, and a feeling isn't a fact you can build on. What's actually true is duller and more useful. A raise done properly isn't a phone call, it's months, the founder's attention pulled out of the work and poured into the raising of money to fund the work, and the two compete for the same finite thing. I've watched enough of it to know you rarely do both well at once. What we're building pitches beautifully, the product and even more the community we mean to grow around it, and it'd be easy to read that as a reason to go and raise. But if I take my eye off the ball to go and sell the ball, the ball is what suffers, and the ball is the whole point. The things that pitch so well are still, honestly, mostly promises. They show beautifully on a slide and haven't had to survive being real yet, and that surviving doesn't happen in an investor meeting. ## Concrete That Hasn't Cured There's a quieter reason, and it's the one I hold most carefully. We've been in a long reflection with the team about how we actually grow together, and it's surfaced real, healthy things, the kind that only come up when people trust the room enough to say them. Good work, and delicate work. What we're laying down in how we hold each other, and how ownership really sits, is a foundation, and a strong one, but it's still wet. You don't build on concrete before it sets, and a raise is a great deal of weight, pressure and expectation and a clock and a new set of people leaning on the structure. So we let it cure first. That isn't delay. It's what makes everything on top of it possible. ## Two Different Games And underneath even that sits the longest question, the one it took me a while to let myself ask plainly. Do we want to raise at all, at this stage, in this way. Because a seed round isn't just money. It comes with a shape. Take it and you've quietly agreed to a certain kind of clock, an exit somewhere around five to seven years, a curve that has to bend a particular way so that everyone who put money in gets it back multiplied. That's a real and honourable game. It just isn't the one I find myself wanting to play. What I want is slower and stranger. I want to build this our way over ten or fifteen years, putting the team first and the product second and the valuation a distant third, on the belief that if you do that honestly the value compounds anyway, quietly, and the thing becomes genuinely worth something because it's genuinely good, not because it was inflated to hit a date. There's a version far down that road where we might choose some kind of leveraged move with the right partner, but that's fifteen years away and I can't honestly say yet what it would look like or whether it makes sense. What I can say is the horizon. And the horizon is a personal one too, which I won't pretend it isn't. There's a family arriving, and a stretch of years coming that I only get once, the years the kids are actually in the house. I'd rather spend them present and building something steady than spend them on the treadmill of the next round and the one after that. A stable foundation for them matters more to me than a fast one for anyone else. ## Not Now, and Our Way So the three of these arrive at the same place. Keep the eye on the ball, let the foundation cure, play the long game rather than the fast one. Not never, though, and that distinction matters, because I dismantled my blanket no to capital once already and this isn't me quietly rebuilding it. Just not now, and when it does make sense, on terms that fit the thing we're actually building rather than the thing capital would prefer us to become. Which leaves me one honest question to sit with, the same discipline I try to hold every time a decision flatters me. It would be very comfortable to call all of this wisdom. Patience, focus, foundations, the long compounding game, they make a lovely story, and lovely stories are exactly where I've taught myself to be suspicious. There's a version of this where holding back is genuine discernment, and a version where it's just fear of the disruption a raise would bring, avoidance wearing the robes of patience. I don't get to assume it's the first because it's the nicer one to tell. What tips me, when I test it honestly, is that this isn't a no to growing. It's a no to a particular speed and shape of growing, made while I can feel the pull of the other path clearly and am choosing anyway. That's the test I set myself a while back, and this time I think I can say I sat it. Not by refusing the pull, but by feeling it fully and keeping my eye on the ball regardless. The ball, for what it's worth, isn't a metaphor for money. It's the small, real, half-built thing on the bench in front of us, and the people gathered around it who I get to build it with. Being wanted was a fine feeling and I'm glad I let myself have it. But it isn't the thing. The thing is on the bench, still half-built, and I'd rather keep watching it harden into something that lasts. There'll be time for taller buildings, and for being wanted, once the concrete has set. With care, Ben --- # Tending a Fire That Isn't Mine URL: https://blog.askara.solutions/source-journal/Entry-35-Tending-a-Fire-That-Isnt-Mine Category: source-journal Author: Ben Visser Date: 2026-06-25T00:00:00.000Z Hey there, The longest day has come and gone, and the desk I cleared before it is already filling again. I wrote last time that I wanted to stand in the solstice empty-handed, that maximum light was for seeing and not for steering, and then the week did what these weeks do. Five retrospectives across two days, every project we bet on in May coming back to tell us what it had become. A few days after the longest day, the team sat down with the Responsibility Radar for the first time, each of us looking honestly at what we are and aren't actually carrying. By the time the noise settled I was on the far side of the hinge with a pile of what the cycle had surfaced, and the sharpest thing in it wasn't a project at all. It was a small fire I hadn't lit. ## What China Lit We don't let the calendar run us, but we do let it tune us. The work moves in six-week cycles, and around them sit the larger turnings, the solstices and the equinoxes, when we stop and re-read the goals we set against the season we're actually in. This is one of those turnings, and the reason I've given it four weeks instead of the usual two isn't that anything has gone wrong. It's that the hinge is a deep one, the European summer slows whether you want it to or not, and there's something this time that needs more than a fortnight to tend. What needs tending began in China. I went looking for nothing in particular and came back having seen something light up in Zach and Simon, a spark of the thing that makes a person pick up a piece of the work and carry it as genuinely their own rather than as a task handed down. Out of that, after the trip and not before, an idea grew that none of us had been holding when I left. A way of taking clients through compliance together, as a cohort that leans on each other rather than each grinding through it alone. It's still a spark. These four weeks are where we kindle it, feeding it the rough shape of the coming six months, the firmer detail of the next three, and the full clarity of the six-week cycle ahead, down to the frame each piece of work enters by, the appetite we'll spend on it and the boundary of what it is and isn't. And the thing I keep noticing, tending it, is that the fire isn't mine. My job isn't to be the flame. It's to make sure it has air. ## The Stage That Asks a Different Leader That's a harder shift than it reads, and it isn't one I've come to from nowhere. I've written before, more than once, about a team moving through stages, and how each stage asks a different kind of leadership from the person at the source of it. In the early days the work wanted me directive, out in front, holding the route and handing out the next clear step, because that's what a young team with everything still to define actually needs. What these four weeks are making plain is that we're not there any more. The team has grown into a stage where directing it is the wrong instrument, where the most useful thing I can do is coach rather than command, ask rather than answer, and hold the conditions in which they find the route themselves. And it asks something of me before it asks anything of them. I have to go through the transformation myself, not just decide on it, and build the actual resources for it, the structures and the practices that let a coaching kind of leadership be more than a word I use about myself. There's a quiet grief in that, a letting go of the version of me who was always the one with the answer. But that version can't kindle what Zach and Simon are carrying. He'd only smother it with his own certainty. The cohort idea has its own gravity now, and a good deal of it isn't even mine to hold. China taught me this as a feeling, the way the gaps I left filled with someone other than me. This is the first time I'm taking it on as a deliberate change of role rather than a lesson I keep relearning on instinct. ## Six Weeks, Not Six Months This is also where I'm reminded why we work in such short cycles at all. The point of them isn't speed. Plenty of companies move faster than we do. The point is that the longest we can be quietly pointed the wrong way is one cycle, because the retrospective and the cool-down are always waiting at the end of it to ask whether the last six weeks were true. A company that runs flat out without that pause doesn't get the question until much later, at the half-year mark or the annual review, by which time a wrong turn has hardened into plans and budgets and is painful to undo. We catch in six weeks what others discover in six months. Not because we're cleverer, but because we refused to treat reflection as the thing you do once there's time, and built it into the structure instead. ## The Arc Over Europe None of this is only about the turns we choose. The same rhythm that catches our own wrong steps is what lets us feel the larger ones, the shifts that arrive from outside and move the ground regardless of our plans. I've written before about reading the sky alongside the build cycle, not as prediction but as a way of staying honest about the fact that we're small and the forces we move inside are not. In August a total eclipse crosses Europe, the first to touch the mainland in nearly thirty years, its shadow arcing from the far north down through Iceland and into Spain, a line drawn across the whole continent rather than a point on it. There's a synchronicity in the timing I can't help noticing. The NIS2 obligations we've spent so long describing as something coming are, this very year, becoming something arrived, audited and enforced across the member states. The market stops being persuaded and starts being compelled, just as we turn the platform outward to meet it. I don't think the eclipse causes any of that, and I have to watch myself here, because it would be very easy and very flattering to let the sky agree with me, to read an arc over Europe as the universe blessing a plan I already wanted. That's the same trap as calling every detour wisdom. The eclipse doesn't know about Askara. What it can honestly be is a marker that a large change is landing inside our window, the kind that moves whether we're paying attention or not. The rhythm is what makes sure we are. You don't get to choose when the ground shifts under you. You only get to choose whether you've kept the habit of stopping often enough to feel it move. So that's where the long light leaves me. Not with a plan I'm defending, but with a small fire to tend, a role I'm choosing to grow into before the work forces me, and an arc forming over Europe that I mean to be awake for. The desk is filling again, and for once I'm not rushing to clear it. There's a difference between a company that moves fast and a company that turns well, and between a founder who insists on being the fire and one who keeps it fed with air. I'd rather be the second of each, six weeks at a time, with just enough light to see by. With care, Ben --- # Reclaiming the Part of Me That Wants to Build Big URL: https://blog.askara.solutions/source-journal/Entry-34-Reclaiming-the-Part-of-Me-That-Wants-to-Build-Big Category: source-journal Author: Ben Visser Date: 2026-06-17T00:00:00.000Z Hey there, In this time before the solstice I'm clearing the desk and look back at the intents I set for myself in December, the way I've learned to do before a turning point. I said I wanted to keep this week for seeing rather than steering. What I keep returning to, though, isn't the conversation on the horizon I wouldn't name. It's one of those December intents, and how absolutely I wrote it. We would grow on subsidies and partnerships. No VC. I want to actually think that one through again with what the last six months have taught me, rather than leave it as a decision I made once and then stopped questioning. ## Why I Drew the Line So Hard The real reason underneath "no VC" was never about dilution or control, though that's how I'd have explained it. It was about the kind of company I want Askara to be. Most companies are built to maximise profit and growth, and venture capital is the engine of that. It feeds the appetite for more, and underneath the appetite is a way of seeing the world that runs on competition and separation. I've taken a lot from Charles Eisenstein here, the idea that we could build around relationship and being instead. The relationships inside the team, with the world around us, with our own inner lives, and the sense that growing as people matters more than growing the numbers. In the old story all of that gets sacrificed for material growth. I didn't want to wire Askara into the engine of the old story, so I wrote "no VC," and it felt like principle. ## The Investor I'd Already Decided About The first thing that line was carrying was a caricature. The investor as parasite, the one who takes as much as he can as early as he can and leaves the founder hollowed out inside his own company. Over these last months I had reason to look at that properly, to understand how a good investor actually thinks rather than how I'd assumed. And it doesn't hold up. A VC worth having needs the founder still motivated through several rounds of raising, because that's the only way the company gets anywhere worth going. Which means grabbing as many shares as possible at the start works against them. They have to leave you enough that you still want to build. There's an alignment in that the parasite story had no room for. So the thing I'd been guarding against was, at least partly, a story I'd told myself. ## The Refusal Underneath But losing the caricature didn't lose the no. Something held underneath it, and when I looked at what, it wasn't all principle. Part of it was simply a refusal. There's a part of me that keeps money and power at a distance and calls the distance a value, because that is a good deal cheaper than learning to relate to them. A flat no costs nothing and sounds like integrity. Some of "no VC" was protecting the company. Some of it was protecting me from having to hold something I would rather refuse than understand. And the something, when I'm honest, is a part of myself. There's an ambitious part of me that wants to build something big, that wants Askara to be large and to matter at the scale these problems actually live at, and somewhere along the way I'd quietly decided that part wasn't really who I am. It was easier to disown it and make money the villain than to admit I'd exiled a piece of myself, and hidden it somewhere a principle would keep it out of sight. ## Through, Not Past This is the thing I've been slow to really take in, even though I write about it often enough. You don't grow out of a part of yourself by banning it. The drive to compete, to acquire, to build the thing bigger, is not a lower place you leave behind on the way to something more relational. It isn't one or the other, where you grow from the first into the second and drop the first. You grow through it. And growing through it means reclaiming it, taking that ambitious, build-it-big part of me back out of the shadow and learning to carry it consciously, rather than leaving it exiled and pretending the wanting isn't mine. You learn to use it on purpose instead of letting it run you from underneath as unconscious programming. A blanket ban doesn't put that drive in its place. It keeps it in the dark, where it can't be trusted, and where it ends up steering more than I'd care to admit. Held consciously, capital and growth are instruments. They serve what the company is for. The trouble only starts when you let them decide what it's for. Which is exactly where I have to be careful with myself, the same way I was careful last time about the shadow in the water. A leader who always finds the silver lining is a leader nobody can hold to anything, and this is a silver lining. I've grown, the ban was only my shadow, so loosening it must be wise. That's a very comfortable story, and I don't get to call it wisdom just because it suits me. There's a version of this where softening the no is genuine integration, and a version where it's the old appetite for the exciting thing wearing more grown-up clothes, the pull I know by now to be one of my more reliable weaknesses. The work isn't landing on the nicer answer. It's walking the question consciously, asking honestly which this is, wise or an excuse, and staying in that not-knowing rather than resolving it the way I'd prefer. The walking is the integration. Becoming conscious enough to ask is the whole point. It's what keeps the drive from running me, and it's the only real guard against trading one unconscious pattern for its mirror image. The test of whether I'm holding the appetite rather than being held by it is simple enough. Can I feel the pull toward the exciting thing and choose, deliberately, not to move on it. So I'm not changing the stance here. I'm taking a sentence I wrote once and then stopped reading, and reading it properly again, holding both the part that was wise and the part that was just me looking away. The conversation on the horizon stays unnamed, and I still won't reach for it. Seeing isn't steering. But it turns inward as easily as out, and this week what it caught was my own hand. I'm holding the mirror up to myself before the retrospectives ask the team to do the same. That still feels like the only honest order to do it in. You walk into the light before you ask anyone else to. With care, Ben --- # When My Plans Failed and I Called It Wisdom URL: https://blog.askara.solutions/source-journal/Entry-33-When-My-Plans-Failed-and-I-Called-It-Wisdom Category: source-journal Author: Ben Visser Date: 2026-06-11T00:00:00.000Z Hey there, Next week the year turns. The summer solstice falls on the night of the 20th, and by one of those alignments I've stopped calling coincidence, our build cycle closes in the same week. The calendar ahead is a wall of retrospectives, five of them across two days, every project we bet on in May coming back to tell us what it became. And a few days after the longest day, the team sits down together for something we've never done before, which I'll come to. The whole week has the shape of a hinge. I've learned to treat these turning points deliberately, to clear the desk before crossing rather than rush on into the next cycle. So before the light peaks I want to look back at what I set in motion when the year began, because something about it has quietly rearranged itself in my understanding. ## What December Wrote At the end of last year I used this journal to set three objectives for myself as CEO. Partnerships and funding. Trust and compliance. The capability of the team. I wrote them with conviction and hung plans off each one, the way you do in December, when the year ahead is a clean sheet and plans feel like promises. Half a year later, every objective is alive, and almost none of the plans survived contact with the year. Take the trust building. The plan said one significant training each quarter. The first quarter delivered exactly that, our first NVC training, a day that brought real tensions to the surface and gave us language for them. The second quarter delivered no training at all. What it delivered instead was something nobody had scheduled. Out of conversations that kept circling the same question, who is actually carrying what, a practice emerged that we've started calling the Responsibility Radar: each person assessing for themselves where their ownership genuinely lies, rather than where the org chart says it should. The team sits down with the full picture a few days after the solstice. It isn't a training. It's closer to a mirror, and it's doing the work the trainings were meant to do. The other objectives tell versions of the same story. Compliance found fronts I hadn't mapped, and the partnerships matured through relationships that arrived sideways rather than down the pipeline I'd sketched. Reading the December entry back, what strikes me is that the objectives were never really plans. They were intents, written wider than I realised. And intents, it turns out, behave like water. The destination holds. The route finds itself, around obstacles I couldn't see from the mountain top, through terrain that only revealed itself by being travelled. ## The Same Water, Closer In There was a fourth objective in that December entry, quieter than the others because it was mine alone. To grow into the leader who can deliver a hard truth without diminishing anyone. I framed it then as a skill to acquire, the skill of difficult conversations, and I imagined acquiring it the way you do in December: practice, feedback, improvement. What actually happened ran a different route. That first NVC training wasn't only for the team. I carried on afterwards in personal coaching with the same trainer, sessions that weren't training and weren't therapy but something closer to this journal made audible, the unfinished thinking spoken until it finished itself. Those months were the build-up to China, where the whole thing landed in the body rather than the head. And the lesson China returned was almost the inverse of what I'd set out to learn. I wanted to get better at speaking. I grew by learning to receive. The objective held. The route ran through silence rather than speech, through listening rooms and train windows rather than conversation technique. Water again. I set the intent at the mountain top and the year chose its own way down. ## The Shadow in the Water And here is where I have to be careful with myself, because I notice how comfortable this story is becoming in my mouth. Intents behave like water, the route finds itself, the plan was never the point. It's true. It is also exactly what I would say if I had simply failed to do the thing I promised. The training that never happened in the second quarter became the Responsibility Radar, and I can call that emergence. I could also be calling drift wisdom, teaching myself that whatever happened was what was meant to happen all along. There is a shadow in the water metaphor, and the shadow is that a leader who always finds the silver lining is a leader nobody can hold to anything. I don't yet know where the line runs between trusting the route and excusing the detour. What I know is that the question has started to make me uncomfortable, and I've come to trust that discomfort more than the serenity it interrupts. ## Maximum Light So this is how I want to arrive at the solstice. Not with conclusions, the real review comes after, once the retrospectives have spoken. Just with the pattern clear in my hands, and the question held open beside it. A few days after the longest day, the team will hold up the Responsibility Radar, and each person will look honestly at what they are and aren't carrying. I can't ask that of them and quietly exempt myself. This entry is me going first, holding the same mirror up to my own year, including the parts where I can't yet tell wisdom from alibi. It feels like the only honest way to lead a practice like that. You walk into the light before you ask anyone else to. The stretch ahead is solar, expansive, outward, the way I described it in the spring when I wrote about tracking moon cycles alongside product cycles. The eclipse still waits over Europe in August. And something has begun to move these last few weeks, a conversation arriving from a direction I wasn't watching, the kind that could give a European push the fuel to actually become European. I'm not going to name it. It's still more pressure than shape, something under the surface I can feel without being able to read. To name it now would be to start steering it, and I've just spent six months learning what that costs when I do it too early. So I'll wait for the light. Between here and the eclipse sits the longest day, and I mean to stand in it empty-handed, the way the trip taught me. Maximum light is for seeing, not for steering. Whatever is rising will show its shape when there's enough light to see by, and I'd rather receive it whole than reach for it half-formed. Whatever wants to come through next, the desk is clear. With care, Ben --- # The Stakeholder Triangle URL: https://blog.askara.solutions/articles/The-Stakeholder-Triangle Category: articles Author: Ben Visser Date: 2026-06-11T00:00:00.000Z When an organisation decides it needs ISO 27001, the first instinct is almost always the same: find the most technical person in the building and hand them the certificate. The one who knows the firewalls, who can read a control like a sentence, who already speaks in acronyms. It feels logical. Security is technical, so a technical person should own it. I have come to think this is one of the more expensive mistakes a company can make at the start, and it took me a while to see why. The person who should own your certification is not your most technical person. It is your best diplomat. ## The Triangle You're Standing In The moment you take on a certification, you are not really standing in front of a documentation problem. You are standing in the middle of a triangle, and you have to keep all three corners happy at once. The first corner is the management team. They hold the budget, the authority and the time, all of which you will need and none of which they will give away easily. The second corner is the auditor, internal and external, who arrives with a process of their own and a list of things they need to see. The third corner is the people, everyone who actually does the work the controls are meant to protect, and who will quietly decide whether any of this becomes real. Certification looks like a paperwork exercise from the outside. Spend a month inside one and you realise the paperwork is the easy part. The hard part is that you are constantly negotiating between three groups who want different things, on different timescales, in different languages. You will never please all three perfectly. The skill is keeping all three satisfied enough that the work keeps moving. That is not a technical skill. That is stakeholder management, and it is the capability the whole thing rests on. ## What Each Corner Needs Each corner of the triangle asks something specific of you, and they are not interchangeable. The management team needs buy-in that is genuine, not performative. There is a version of compliance that exists only because a tender demanded it, and everyone involved can feel the difference. The work goes cold the moment the deal closes. What you actually want is the intrinsic version: a leadership team that understands, in their own terms, why having security in order matters to the organisation regardless of who is asking. Getting there is the real first step. It is the trigger for everything downstream, and nothing lands properly until it exists. Once you have that commitment, your job flips from convincing them to protecting their time. Leadership does not want to wade through risk methodology. They want clear, pre-chewed decisions. The mechanism that makes this work is the management review, ideally run every quarter, where you bring the few decisions that genuinely need their attention. Each one arrives as a yes or no: here is the problem, here is what I think we should do, here is roughly what it costs. Quantified, decided, done. Do this well and the management review stops being a box to tick and becomes the engine room of the whole programme. The auditor needs a relationship that surprises most people. The instinct is to treat the auditor as an examiner, someone to survive. The better posture is to treat them as an ally. There is genuinely more administrative weight to an audit than you expect: scheduling, coordination, the records that auditors themselves have to keep so they can show their own accreditation body they are auditing properly. Absorb as much of that planning burden as you can. Then prepare your people, because the part that quietly derails audits is the interview. Staff hear the word audit and imagine an exam they might fail, and they get nervous for no good reason. A short, honest brief on what an interview actually is removes most of that fear. What comes back out of the audit is findings, and findings are not a verdict. They are input. They get documented, turned into plans, decided on with the management team, and then landed with the people. The auditor is one corner to manage, and how you choose one in the first place is a separate question [worth its own article](https://blog.askara.solutions/articles/Youre-Choosing-a-Person-Not-a-Certificate). The people are where all of it has to actually land, and they are the corner most programmes underinvest in. Roughly eighty per cent of risk lives in human behaviour, which means every decision you make and every finding you close is only as real as the behaviour change it produces. This is where you sit down with the groups that matter: HR around joining and leaving, operations around using tools safely, IT as the support layer underneath, and the suppliers and partners who need to understand how you expect them to work. None of this is about watching anyone. It draws only on what an organisation already does and already knows about itself. The difference between landing here and not landing here is mostly tone. You do not want to be the person who walks in and the room thinks, here he is again about passwords. You want people to find it interesting, even enjoyable. That sounds soft. It is the whole game. ## The Job That's Left After the Paperwork For most of the history of this work, something like eighty per cent of the effort went into getting documentation in order. Writing it, formatting it, keeping it current, producing it on demand for an auditor. It was the bulk of the job, and it was the part nobody enjoyed. That part is now largely automatable, and this is the quiet shift I find genuinely exciting. When the documentation produces itself from what is actually happening, that effort does not disappear. It gets freed. It can go where it was always supposed to go: to the people, and to actually improving how an organisation behaves. This is the direction we are building toward at Askara Solutions, automating the paperwork so the human part can take centre stage rather than fighting for the scraps of time left over at the end of a busy week. A few small things start to become possible once that time exists. Communication is the first thing to collapse when work gets busy, and it is the most damaging thing to lose, so having AI help draft an update or a report means the thread does not go quiet for a fortnight. Training can stop being an annual event nobody remembers and start happening at the right moments instead: a short microtraining triggered by an after-action review when an incident gets logged, while the lesson is still warm. A business continuity exercise can be run with the whole team as something closer to a light escape room than a fire drill. These are illustrations, not the point. The point is that the time to do them only exists once the paperwork stops eating it. ## The Person to Appoint So when someone asks who should own this, I no longer point at the org chart and look for the most technical name. I look for a profile. Someone who can stand firm enough to be taken seriously by the management team, and talk to them at their level without flinching. Someone who can sit across from an auditor as a partner rather than a suspect, neither intimidated nor defensive. And someone who is genuinely likeable to the people, who can make the unglamorous parts of security feel worth caring about rather than worth avoiding. That is a diplomat, not an administrator. And it is worth noticing what kind of work this actually is. The paperwork was the part a machine could eventually do. Holding three sets of human interests in balance, reading a room, building real buy-in, making people care, that is the part no machine is going to take from you. It also happens to be the part worth enjoying. The certificate was never the prize. The conversations on the way to it were. --- # You're Choosing a Person, Not a Certificate URL: https://blog.askara.solutions/articles/Youre-Choosing-a-Person-Not-a-Certificate Category: articles Author: Ben Visser Date: 2026-06-11T00:00:00.000Z Most companies choose a certification body the way they choose a courier. Get three quotes, glance at the logos, pick the one that looks reputable and lands in the middle on price. Then they wait to find out who actually turns up. Here is the thing nobody puts in the procurement checklist: the price and the logo are not what shapes your audit. The human who walks through the door is. And whether you will ever see that human again matters more than almost anything you compared on the spreadsheet. The third audit with the same auditor is worth more than the first three with three different ones. This is part two of a short series about the parts of compliance a machine cannot do for you. The first piece looked at the three people whose buy-in an information security management system actually runs on: your management team, your auditor, and your own staff. Call it [the stakeholder triangle](https://blog.askara.solutions/articles/The-Stakeholder-Triangle). This piece zooms into one corner of it, the auditor, and asks a question the speed-obsessed market almost never asks. Not how do you pass the audit, but how do you choose the person who runs it. ## Big Body, Small Body There are two kinds of certification body, and the difference is not really about quality. It is about whether you are a relationship or a row in a database. The large bodies are built for scale, and scale has a logic. They run internal allocation desks whose job is to match an available auditor to a slot in your calendar. If your auditor is unavailable, someone else is scheduled. Across the three-year certification cycle there is rotation by design, so it is entirely possible to sit across from a different person each time, explaining the same context about the same topic to someone who has never heard it before. None of this is incompetence. It is just what an org chart optimised for throughput produces. You are handled efficiently, and you are handled by a number of people, and you are, to the system, a number yourself. The small bodies work differently because they cannot afford not to. Often the person auditing you is the person who owns the firm, working with a handful of colleagues, doing the job because they genuinely like it. I have sat across from an auditor like this, someone with real love for the craft, who clearly enjoyed the conversation, and who turned what could have been a grim formality into something I looked forward to. That is not a small thing. An audit you look forward to is an audit that does you good. ## Why Continuity Compounds Here is the part the market structure quietly hides from you. A returning auditor is not just more pleasant. They are worth more, and the value compounds. Think about what happens on a second or third visit with someone who already knows your history. They remember the trade-off you made last year, the one where you accepted a risk for a reason that made sense at the time. So they can reopen it: is that still the right call, now that you have grown? They build on previous findings instead of starting from zero. They know where this particular company tends to be strong and where it tends to drift, so they push a little harder exactly where pushing helps. None of the session gets spent on re-establishing context, because the context is already shared. Every minute goes to the actual work. Now run the alternative. A new auditor each cycle, each one fed the same introduction, each one forming first impressions you have already corrected twice. You are not building anything. You are re-explaining. The audit becomes a reset rather than a step forward, and you pay for that reset in the most expensive currency you have, which is the time of the people who understand your business. So this is the anchor I would offer: continuity is the asset. Not the certificate, not the logo on it. The certificate is the same piece of paper either way. What differs is whether the relationship behind it accumulates value or starts over. ## Choosing Well, Up Front You have more control over your audit experience than the procurement framing suggests, and almost all of it is exercised before you sign anything. Choose locally. Choose someone who works in your language, understands your culture, and recognises your way of operating without needing it translated. Favour a relatively small body where keeping a personal bond with one auditor is realistic rather than accidental. And approach the relationship as a partnership, not an examination. The auditor is not there to catch you out. The good ones are there to make the thing genuinely better, and they respond to being treated accordingly. This is also where I want to be precise about Askara Solutions, because it would be easy to misread what we do here. We will help you choose. We can hand you the few things to look for, the questions to ask, the signals that tell you whether a body will treat you as a partner or a ticket number. What we will deliberately not do is sit in the middle of it. No preferred-supplier arrangement, no broker fee, no Askara-shaped layer between you and the person auditing you. The moment a third party inserts itself into that relationship, it starts to behave like a staffing agency, with its own reasons to keep you moving and churning, and the direct long-term bond is exactly what gets sacrificed. The relationship is yours. It should stay yours. The most useful thing we can do is help you start it well and then get out of the way. This is, when you look at it plainly, the whole reason these choices cannot be automated. An allocation desk can match a calendar slot. Software can compare prices and surface logos and rank bodies by turnaround time. What none of it can do is judge whether you will trust this particular person across three years, or build the rapport that makes the third audit worth more than the first. That judgement, and that relationship, are stubbornly, permanently human. The audit you dread is not really the audit. It is the prospect of a stranger arriving to grade you. Choose the person instead of the price, choose someone you can keep, and the thing inverts. It becomes a standing appointment with someone who knows your company, wants it to be better, and helps make it so. The machines will take more and more of the compliance work off your hands. Good. That just leaves you the part that was always worth keeping. --- # The Case for Doing Less as a Founder URL: https://blog.askara.solutions/source-journal/Entry-32-The-Case-for-Doing-Less-as-a-Founder Category: source-journal Author: Ben Visser Date: 2026-06-03T00:00:00.000Z Hey there, The first week back is always its own strange thing. You step off the plane carrying the rhythm of where you've been, and for a few days it sits awkwardly against the structure you left behind. Neither quite wins. You spend the time working out which parts of the trip stay with you and which were only ever for the trip. Before I left I'd written that May was the middle part of the cycle, the rivers running while I stayed deliberately absent, and that my job on returning was simply to receive whatever the terrain produced. This is the entry about what I came home to. And about how much harder receiving turned out to be than writing the word. ## The Room I Came Back To We opened with a mega sync, the whole team together in one place for the first time in weeks. There's a particular quality to that kind of meeting when you've been genuinely gone. You're not really catching up. You're taking the measure of what moved without you. And as I sat there listening, what became clear wasn't that the team had carried everything further than I would have. If I'm honest, the opposite kept surfacing. I could see, often quite precisely, the places where my input had been missing. The decisions that would have gone differently with me in the room. The small things I'd have caught. The old instinct is to name those things, to gently restore the route I'd have taken. But the longer I sat with it, the more I understood that the gaps were the point. The team needed to feel my absence directly. They needed to run into the places where they'd been quietly relying on me, without either of us noticing, because that's the only way it becomes clear where they have to step up. You can tell people they have ownership. It stays abstract until the person they were leaning on simply isn't there and the thing still has to get done. My work isn't to fill those gaps back in the moment I return. It's to keep building the conditions in which they get filled by someone other than me, until independence stops being something I hope for and becomes how the team actually operates. That's a strange thing to sit with in a meeting. Watching something you'd have done better, and choosing not to touch it. ## What Settled in Me My own clarity didn't arrive in any single moment. It came back the way rhythm does after travel, slowly, as the structure of an ordinary working week reassembled itself around me. What surfaced wasn't a new direction. It was closer to the opposite. Part of stepping out had been catching up, from a distance, on what others in our space are doing. The old familiar pull came with it. The sense that we should be doing more, adding the cleverer thing, answering the competition with another idea. I've learned to recognise that pull by now. It's one of my more reliable vulnerabilities, this appetite for the next idea, the seductive addition that always feels like progress and so often is just motion away from the unglamorous work of finishing what's in front of you. What the distance gave me was room to remember that we stand exactly where we need to stand. The full fleet of agents we mapped out over the accelerator, Risk Investigation, Incident Response, Contract Management, Business Continuity, that is the thing. The discipline now is to close it, not to reach past it toward whatever the competitive comparison throws up next. Two weeks of no product thinking did what being inside the work every day never manages. It let the existing shape look complete instead of perpetually unfinished. ## What Arrived Through Simon And then there was the part I genuinely couldn't have produced on my own. After the mega sync a smaller group of us stayed on to talk about the beta programme. Simon brought something he'd been turning over while I was away, the beginnings of an idea for a community based customer platform. Something with more life to it than software behind a login. As we talked it through it kept shaping itself, live in that room, into something neither of us had walked in holding. Clients moving through a yearly certification cycle together, as a cohort, rather than each of them grinding through compliance alone in their own corner. The platform as the connective tissue between them. Shared milestones, the journey made visible to the people walking it alongside you, a community forming around work that is usually isolating and a bit grim. It turns the thing companies dread into something with momentum and company built in. And it gives the software a gravity it never had as a standalone tool. The detail I keep coming back to is when it arrived. It came in after I stopped talking. After two weeks of deliberately not offering the most efficient path before anyone had asked for one. I made the space, and the space produced something better than my steering would have. The shape we ended on was genuinely ours. Not Simon's handed to me, not mine imposed on him. I'm not sure it could have formed if I'd come back full of my own plans. It carried on from there in a way I also didn't engineer. Zach has been finding his place in the same current, building rapid prototyping solutions off the feedback the platform throws up. A role that fits him almost perfectly, and that nobody assigned. The idea opened a space and he moved into it. Rivers finding their own course through terrain I never had to map. ## The Third All of this has been hardening something I'd been circling for a while into an actual decision about where my time goes. A third of it on operations. A third on writing and reflection, the work that keeps me honest and keeps this journal alive. And a third on what I've started thinking of as the social container, the trust and the relationships that hold everything else together. Not a vague good intention but a real allocation. Something like one full morning a week given over to building the tools and preparing the meetings that make the right internal conversations possible in the first place. This is really just the calendar catching up with something I already claimed to believe. That the most important infrastructure you can build is human. If that's true, and if the team's best thinking arrives precisely when I make space rather than fill it, then a third of my time spent tending the container isn't generous or soft. It's the most accurate description of where the leverage actually sits. And the work of that third is not transmission. It's not me pushing direction down through better-run meetings. It's reception. Building the conditions in which whatever the team is carrying can surface and be properly met. I'm not telling myself they can suddenly hold more than before. I'm trusting that whatever they're holding is what it needs to be, and learning, slowly, to receive it well. ## Practising for What's Coming I won't pretend this comes easily. The honest truth is that I still often feel I'd have done the thing better myself. Some part of me probably always will. What's shifting, and it's only just beginning to shift, is my relationship to that feeling. Because being better was never the point. The point is a team that grows into its own capability. And that can't happen in the presence of someone who keeps stepping in to show the cleaner way. I'm finding a kind of peace with that, in fragments, alongside the first real signs that the trade is worth it. There's a sharper reason to keep practising now, too. Around October, Chiara and I are expecting our first child. Another stretch of absence is coming. Only this one won't be two weeks I chose, and it won't end on a return flight. China was a rehearsal I walked into deliberately. This next one arrives on its own terms and lasts a good deal longer. So the work of learning to leave the right gaps, of building the container while I'm here to build it, of becoming someone the team doesn't need standing over them, has stopped being a matter of personal growth in the abstract. It has a date attached to it now. I'd rather meet that date having already practised than discover the lesson under pressure. The sea doesn't strive to be the sea. It just stays lower than everything else, and the rivers find their way down to it on their own. The week back has mostly been a practice in staying that low. Less steering, more gathering. Trusting that what ran downhill while I was gone ran more or less where it was meant to. With care, Ben --- # What China Taught Me About Leading a Team URL: https://blog.askara.solutions/source-journal/Entry-31-What-China-Taught-Me-About-Leading-a-Team Category: source-journal Author: Ben Visser Date: 2026-05-27T00:00:00.000Z Hey there, We went to China for a wedding. Two weeks, Chengdu then Beijing, with the deliberate intention of disconnecting from everything Askara. No AI, no product thinking, no checking in on the team. Just friends, then Chiara, and trusting that whatever needed to surface would find its own way through. China is home to Taoism, one of the world's oldest living philosophical traditions, shaping how this civilisation thinks about nature, leadership, and the relationship between action and stillness for over two thousand years. What struck me almost immediately is how closely it aligns with the way of living I've been cultivating through Source Work, through self-management at Askara, through the instinct that trusting the process is not a platitude but an operational principle. I'd engaged with Taoist ideas before, but always at a distance. Being in the country where they were born, walking Mount Qingcheng where Taoism was founded, reading the Tao Te Ching on a train through the landscape it was written about, all of that collapsed the distance. What had been intellectual became felt. And the lessons were divinely timed for where I am right now. ## The Master Who Kept Talking Over the past year I've written about trust often. Trusting the process, trusting the team, trusting that you can't force the Source. I believed all of it. But this trip peeled back a layer I hadn't fully seen. The layer was control. Not the obvious kind, not micromanagement. The subtler version: having a view on how something should be done and offering it before anyone asked. Seeing the most effective path and pointing it out, even when nobody was lost. The problem isn't being wrong. Often I wasn't. The problem is that offering the answer before the question removes the entire learning experience for the other person. Received knowledge doesn't compound the way discovered knowledge does. Taoism has an idea that the master doesn't teach by talking. The master creates conditions and waits. If a student asks, the master responds. If they don't, the master trusts that the student is working through something on their own time. The master who keeps talking, however brilliant, is serving his own need to be useful. I recognise that pattern in myself. And carried too far, it becomes exactly what I've been writing against. It becomes forcing the Source. ## Action Through Inaction Wu wei. Action through inaction. Not passivity but responsiveness. Not doing nothing but doing only what the moment requires. The Tao Te Ching says the supreme good is like water. Water nourishes all things without competing with them. It flows to the lowest places. And because the sea lies below all rivers, it becomes king of them all. Hearing this on the train, after weeks of deliberately not leading anything, the words rearranged into a complete model for how I want to lead. The water cycle starts at the mountain top. That's the source: the vision, the direction, the clarity about what we're building and why. That part is mine. I set it and protect it. Source Work in its purest form. Then the water flows downhill, finding its own path, splitting into rivers that each respond to the terrain they encounter. This is the team working independently. And this is the part where I don't intervene. The river finding its own path is the entire point. When I redirect it because it's not the route I would have chosen, I'm not leading. I'm eroding the banks. At the bottom, everything gathers. The rivers reach the sea. The sea doesn't command the rivers. It receives them, follows what they found, integrates and holds space for whatever arrived. To lead is to be the lowest point, the place where everything naturally flows together. Then the water evaporates, rises, returns to the mountain. The cycle begins again. At the top, you're the source. In the middle, you're absent. At the bottom, you follow. The whole thing only works if you trust the middle part. ## What Deepens During the accelerator, I already understood a version of this. We didn't need to stress about what the outcome would be. By focusing on the team, on building the relationships that form the container, whatever emerged would be the right thing. External forces like new developments in AI helped shape something we couldn't have predicted at the start. The Risk Investigation Agent, the graph backend, none of it existed as a plan when we began. It emerged because the conditions were right. That insight still holds. But China sharpened it. What's new is trusting at the micro level. Trusting that whatever someone is independently working on is right for a reason in that specific moment. Even when it's not how I would have done it. Even when I can see a faster path or a cleaner solution. The river doesn't need my route. It needs its own, through its own terrain, discovering what only that particular path reveals. The best leader, as the Tao Te Ching prescribes, is the one whose people believe they're doing it themselves. That's not a trick. It's the natural result of a cycle where the source is clear, the rivers are trusted, and the sea lies below. May has been the middle part. The rivers have been running. Whatever arrives when I return is what the terrain produced. My job now is to receive it. With care, Ben --- # Our Startup Story: Askara Solutions x Tehnopol Cyber Accelerator URL: https://blog.askara.solutions/dispatches/Our-Startup-Story-Askara-Solutions-x-Tehnopol-Cyber-Accelerator Category: dispatches Author: Simon Scullion Date: 2026-05-14T00:00:00.000Z Updated: 2026-05-14T00:00:00.000Z Seven months. Tomorrow it's done. And this week, [Tehnopol](https://www.tehnopol.ee/) published the interview they asked us to write as part of their Startup Story series. We applied for the people. That's the honest answer Ben and I gave, and it's held up. The grant matters — of course it does at this stage! But the conversations, the introductions, the being in rooms we wouldn't otherwise have been in. That's what's compounding now. Here's the interview as it ran. --- **Each year, dozens of high-potential startups develop their product or service in Tehnopol Startup Incubator's main programme and special accelerators. One of the teams currently building in the Cyber Accelerator is [Askara Solutions](https://askara.solutions/).** Askara provides agentic cybersecurity compliance for European SMEs. Their AI agents reason through a company's information security management system — covering risk, incidents, contracts, and business continuity — and do the real compliance work, so evidence becomes an outcome rather than the goal. Behind the agents sits a shared compliance "brain" that maps every risk, control, and decision, and improves with every engagement. Askara is founded by Ben Visser (CEO & Founder) and Simon Scullion (COO & Co-Founder). Ben has spent the last eight years deep in ISO management systems, implementing ISO 9001, 14001, 27001, and 55001 in organisations that wanted systems people would actually use. Simon brings over twenty-five years in application development, consulting, and digital transformation, with a recurring focus on how people and technology truly work together. Askara's work was introduced by both of them. ## How did you come up with the idea to create a startup? "The compliance industry sells evidence, not security. Ben had seen it from the inside for years — implementing ISO management systems across multiple standards and watching organisations get certified without ever becoming more capable. With NIS2 bringing 160,000+ European SMEs into scope, that broken model is about to be imposed on the companies least equipped to absorb it. We founded Askara to build the alternative: AI agents doing the real work, with evidence as the byproduct." ## What have been the biggest challenges/failures and the biggest wins so far? "Our biggest internal challenge has been practical: every legal and governance template we touched was built for hierarchical companies. Formalising Askara around self-management — source, sociocracy, and Slicing Pie equity — meant rewriting our shareholder agreement from scratch. Commercially, we're forging a new category in a market dominated by US-first GRC platforms that European SMEs can't afford and don't fit into. The wins: our Risk Investigation Agent is live with our launching customer Qwello. Three more agents are ready to deploy. And CR14 is in conversation for a demo — strong validation from Estonia's defence and cybersecurity cluster." ## What sets Askara apart from competitors? "Most compliance platforms optimise for speed to certificate. Askara is built for what customers actually understand when they're done. We automate compliance work rather than compliance evidence. Our agents return with questions rather than conclusions — keeping human judgement where it belongs. And behind them sits a shared compliance brain that learns from every engagement: every agent grows sharper over time." ## Why did you apply to the Cyber Accelerator? "We applied for the people — the interaction with other participants and mentors, and access to the wider community Tehnopol opens up. That's played out exactly as we'd hoped. We've connected with National Coordination Centres across Europe, joined matchmaking events like Connect4Cyber, attended RIA's cyber meetups here in Estonia, and travelled with the Estonian trade mission to the Cyber Security Business Convention in Toulouse. It's also shaped how we think about funding. Rather than following the traditional venture capital script, we're in conversation with aligned investors and leaning into the European grant and subsidy ecosystem." ## Where do you see your startup in 1 year? And in 5 years? "In one year: our beta programme is complete, the product is launched EU-wide, and our growing suite of compliance agents — risk, incidents, contracts, business continuity, policy generation — is in market alongside a management dashboard. We'll also be ISO 27001- and ISO 9001-certified ourselves. Practising what we preach. In five years: Askara is the first platform European SMEs reach for when cybersecurity compliance obligations land on them — when NIS2, DORA, or whatever comes next brings them into scope. Part of the compliance infrastructure of the EU." ## Who is the next (Estonian) unicorn? "Honestly, we've got our hands full with Askara to keep tabs on the whole field. We'd love to see it come from one of our fellow Tehnopol Cyber Accelerator participants, or a friend made at the cyber meetups. If Askara doesn't get there first…" ## Which books/podcasts/publications and influencers do you recommend? "On the concepts of source and money work: [Peter Koenig](https://peterkoenig.typepad.com/) and Tom Nixon's [*Work with Source*](https://workwithsource.com/). Aligning work around natural cycles: Ryan Singer's [*Shape Up*](https://basecamp.com/shapeup) (Basecamp). For dynamic equity distribution: Mike Moyer's [*Slicing Pie*](https://slicingpie.com/). These frameworks show up structurally in how Askara operates day-to-day. On business philosophy: Yvon Chouinard's [*Let My People Go Surfing*](https://www.patagonia.com/product/let-my-people-go-surfing-paperback-book/BK050.html) and Ricardo Semler's *Maverick*. Two very different companies, same conviction that working differently is a real competitive advantage. [Naval Ravikant](https://nav.al/) is a sharp read on software and content as compounding assets. In our field specifically: the [FAIR Institute](https://www.fairinstitute.org/) and Jack Jones on quantifying cyber risk in financial terms. Foundational to how Askara models risk." --- *Originally published on the [Tehnopol website](https://www.tehnopol.ee/en/startup-story-askara-solutions-x-tehnopol-cyber-accelerator/), 12 May 2026.* --- --- # The Most Important Infrastructure Is Human URL: https://blog.askara.solutions/source-journal/Entry-30-The-Most-Important-Infrastructure-Is-Human Category: source-journal Author: Ben Visser Date: 2026-05-04T00:00:00.000Z Hey there, Seven months ago I walked into the first day of the Tehnopol Cyber Accelerator with a vision that had only just crystallised, a team still finding its shape, and a bet I want to describe in this entry. This is written from the other side of it. ## What We Decided Before We Started When we entered the programme, we made a deliberate choice that I want to name clearly because it shaped everything that followed. We decided that the primary win was not the product. It was the team. We trusted that if we came out of seven months with genuine shared ownership, real trust, and a functioning way of working together, the quality of what we built would reflect that. The product would be a symptom of the team, not the other way around. That bet was harder than it sounds when you are sitting in a room full of founders sprinting toward demos and pitch decks. But holding it taught us something about entrepreneurship that I keep returning to, something that applies just as much to life in general as to any seven-month programme: the most consequential things that happen in a structure like this are never the workshops. They are the human connections, and whether you understand deeply enough that everything else is a derivative of those. ## What This Programme Actually Is Something I want to say directly to anyone reading this who is weighing up whether to apply: this is not the kind of accelerator I went through during my studies in the Netherlands. In those programmes, the money was smaller, a significant portion was earmarked for affiliated organisations, and the structure held your hand at every turn. You could feel the programme managing its own investment risk by managing you. Tehnopol works differently. The funding is real and largely unrestricted. The workshops are genuinely good. The mentorship is active and engaged. But fundamentally, they give you the latitude to operate like an entrepreneur rather than a student. They are betting on the instinct you came in with. That is a little unsettling at first. And then it is deeply refreshing. ## Two Evenings There are two moments I keep returning to because they capture what becomes possible when you are genuinely in the room. The first happened on the way to one of the cyber meetups. Just before leaving, our incident handling agent had received and processed its first real report from a client. I was on the phone with her while walking over, watching in real time as the agent responded and she registered how it had handled her input. By the time I arrived at the venue, Tiia, a postdoctoral researcher from TalTech, was presenting her work on human behaviour and social psychology in cybersecurity contexts. Listening to her frame how people actually behave under the pressure of an incident, I had a fresh and very concrete example of exactly that sitting in my pocket. Afterwards, the conversation almost opened itself. Not because her research was about our product, but because the incident that had just happened was the perfect illustration of where her work and ours could become genuinely complementary, how her insights could inform the way our agents are instructed to handle these situations, and how those instructions could shape the experience on her side of the equation. That same evening, an innovation grant was presented at the meetup with a call for proposals that aligned almost precisely with what we are building. Three threads, one evening. These are the moments you come for. The second moment came through our mentor, Marily. She had been actively involved throughout the programme, with monthly check-in meetings that consistently pushed us past the comfortable answers and toward the questions we had been avoiding. At one of the meetups, she used her position within the network to arrange a one-minute open request slot for us with the facilitator. That one minute led to a conversation with the CISO of CR14, one of Estonia's most significant cybersecurity organisations, which is now one of the most promising leads we are carrying. That is not something you engineer. It is something that happens when someone who genuinely knows the room decides to use their relationship capital on your behalf, and it happened because of seven months of showing up and building something real with her, not because of anything on our pitch deck. ## The Ecosystem as Outcome Looking back across the seven months, what the programme ultimately gave us was not knowledge or funding or even specific leads, though it gave us all of those things. What it gave us was terrain. A genuine sense of how this region operates, how advanced the Nordic and Baltic cybersecurity community already is, and how much there is to learn by working alongside the right partners rather than simply selling to them. Through the Connect4Cyber event in January, promoted through the same network, we made contact with Turku University of Applied Sciences, a hidden gem of cybersecurity expertise with deep experience in EU subsidy landscapes we are still learning to read. That connection has opened thinking about what collaborative proposals across the region could look like. Our orientation, which I wrote about in the entry on playing the European game, is to become a known contributor in the Nordic cyber community through collaboration rather than through aggressive sales. The accelerator gave us the relationships and credibility to make that real rather than aspirational. But none of it would have materialised by sitting in the workshops and making notes. The programme is an ecosystem, and ecosystems reward those who participate in them fully, who show up for the meetups, who follow through on every conversation, who understand that the facilitator's network is accessible to the mentor who trusts you because you have spent seven months being worth trusting. The leads, the grants, the collaborations are all derivatives of the human connections that either get built or do not. That is the thing about entrepreneurship that this programme, more than any other I have been through, actually tests. You can be handed an extraordinary amount of potential and walk away with very little, simply because you did not understand what it was really made of. ## Full Circle We entered with a bet on the team. We are leaving with a team that earned that bet, and with everything that flows from having made it. The relationships that are converting into real opportunities, the trust that makes genuine collaboration possible, the clarity about how to operate in a region doing something important that the rest of Europe is still catching up to, all of it traces back to the same root. Everything since the first day has been a reminder that the most important infrastructure you can build is human. With care, Ben --- # Why I Track Moon Cycles Alongside Product Cycles URL: https://blog.askara.solutions/source-journal/Entry-29-Why-I-Track-Moon-Cycles-Alongside-Product-Cycles Category: source-journal Author: Ben Visser Date: 2026-04-16T00:00:00.000Z Hey there, I'm writing this from a plane on Wednesday morning, somewhere over the Baltic. Tomorrow evening I deliver the pitch that formally closes our seven-month accelerator programme. On the same day, our Risk Investigation Agent goes live as a purchasable product, and the graph backend behind it enters beta with a select group of users. Seven months of behind-the-scenes work about to crack open to the outside world. For years now I've paid attention to how celestial rhythms line up with the patterns of my own life. Not as prediction, more as a way of reading where I am within a larger current. This past week, listening to a detailed breakdown of the astrological events surrounding this period, something clicked into sharper focus. Dots I'd already been sensing connected into a picture worth sharing, because it maps so closely onto what we've been living through at Askara Solutions. ## The Blood Moon Broke On March 3rd, a total lunar eclipse passed over the Pacific and the Americas. A Blood Moon, the last one the world will see until New Year's Eve 2028. Almost three years from now. February and March brought the most difficult conversations we've had as a team. The kind that surface when people have worked closely enough and long enough to stop being polite about what isn't working. Tuckman calls it storming. We wrote about it before, during the retreat in Tallinn when we first saw each other's shadows. But this round was different because it happened within the existing structure. We kept our time slots. We held our meetings. Nobody escalated beyond what the rhythm could hold. The storms moved through the system rather than blowing it apart, and honestly that's the more impressive version of the story. It means the container works. The accelerator programme had been functioning as exactly that kind of container since October. Funding that freed us from client pressure. A deadline that demanded we build something real. A small team pushing toward a shared goal under genuine constraints. The whole programme was a contraction, seven months of turning inward, building beneath the surface, working through friction that high-trust teams simply have to work through if they want to get to the other side. The Blood Moon closed that chapter. Not because I decided it did, but because something shifted in the weeks after. Conversations became calmer. Alignment got clearer. What had been turbulent started settling into something you could actually stand on. Astronomers describe the stretch between now and late 2028 as a period without total lunar eclipses, characterised by what some call solar cycle energy, expansive rather than contractive. Whether or not you take that literally, the felt sense matches. We are moving out of necessary inward pressure and into something that wants to open. ## The Hallway We Built Tomorrow evening, the Risk Investigation Agent becomes something people can actually buy. And the graph database solution behind it, the one that maps logical relationships between risks, controls, and management decisions, enters beta with a carefully chosen group. I want to be specific about what this means technically, because the architecture is what makes it real. The Risk Investigation Agent takes a company's context, their sector, size, regulatory obligations, existing controls, and reasons through their risk landscape the way an experienced consultant would. Not pushing them through a generic checklist but understanding what actually matters for their specific situation. It can do in days what traditionally takes months, and it does it at a price point that makes sense for the SMEs who need it most under NIS2. The graph backend is something else entirely. It checks whether a management system's internal logic actually holds together. When a company says a particular control mitigates a specific risk, the graph can trace that reasoning and verify whether it makes sense given everything else in the system. We first glimpsed this possibility during an ISO27001 audit last autumn, when our auditor walked us through a wheel metaphor with risk at the hub, and that idea collided with the knowledge graph work we'd already been doing. What started as a conceptual insight has become working software. Launching both on the same day wasn't planned that way from the start, but it makes sense now. The agent is immediate, accessible, demonstrates value within minutes. The graph is the deeper architecture that makes the whole system coherent over time. Together they represent something we couldn't have forced into existence by sitting in a room and brainstorming. They grew out of the kind of patient, sometimes uncomfortable foundational work that the accelerator made space for. April 15th, the day I boarded this plane, carries its own weight historically. A date people associate with endings and sharp turns. But what we're stepping into on the 16th feels nothing like that. It feels like walking through a door we've been building the hallway toward for seven months. ## Doubled Light May brings something rare. Two full moons in a single month, the second of which is called a Blue Moon. It happens roughly every two and a half years. And this time it falls in a month that matters enormously for us, though not for the reasons you might expect. I'll be travelling for most of May. China, among other places. I expect it to be confronting in the best sense, sustained exposure to a part of the world that operates on completely different assumptions about technology, governance, and collective effort. The kind of culture shock that stays with you. Which means the team will need to run without me for an extended stretch. Properly, for the first time. I should be honest here. We are not yet the kind of team that operates seamlessly without any single person at the centre. That's the aspiration, not the current reality. May will be the experiment that shows us how far we've come and where the gaps still live. Simon and I had some of the most honest conversations we've had in recent months about what this requires, conversations that were themselves part of the storming I mentioned earlier. What came out of those exchanges was a clarity about what needs to be true before I leave. We're using a team weekend as a hackathon specifically focused on this. Async communication, ownership structures, making sure every person understands their own mission clearly enough to take extreme ownership of it. Not waiting for direction from me but operating from a deep enough understanding of the whole to make the right calls on their own. The accelerator closes officially in May too. So you get this overlap where a contraction is completing and an expansion is beginning at the same time. The beta programme runs through Q3, building toward something much bigger. I keep thinking about something I wrote early on, about how you can't force the Source. That the organic trigger for momentum has its own schedule. Stepping away for a month is the most radical version of that principle I've tested yet. Either the conditions we've built hold, or they don't. And I won't know which until I actually let go. The Blue Moon feels right for that. Doubled light in a month of deliberate absence. Not because I'm confident it will all work perfectly, but because the only way to find out is to run the experiment. ## Eclipse Over Europe On August 12th, a total solar eclipse will cross over Iceland, northern Spain, and Portugal. The first total solar eclipse for mainland Europe since 1999. Almost three decades. That timing lines up with something specific for us. The graph beta programme runs through Q3, and the goal is to move into alpha by Q4, which means European-wide availability. While a once-in-a-generation solar eclipse moves across the continent, we'll be in the final stages of proving whether our technology is ready to serve it. The eclipse feels like a marker on that timeline. When we started playing the European game through Connect4Cyber, through the subsidy ecosystem, through founding in Estonia, it was still somewhat abstract. An identity we were growing into. By August, if the beta delivers what we think it can, that identity starts becoming operational. There's a pleasing symmetry in the celestial calendar here. March's Blood Moon closed the internal contraction. May's Blue Moon tests whether the team can stand on its own. And August's solar eclipse, visible across the continent we're building for, arrives right as we prepare to open up to it properly. I don't want to overstate this. These are markers, not prophecies. But I've learned to pay attention when the external rhythm and the internal one start moving in step. It usually means you're tapped into something real. ## What Remains The accelerator gave us seven months of protected space. In that time we worked through the hardest internal conversations within the structures we'd built, and came out the other side with two products worth launching. Tomorrow we step through the door. In a few weeks I step away and find out what this team is actually made of. And in August, Europe gets its first total solar eclipse in nearly thirty years, right as we prepare to show up across it. Between now and late 2028, no more Blood Moons. Just solar energy. Expansion. Outward movement. I don't know what all of that will look like yet. But I'm learning that not knowing might actually be the point. With care, Ben --- # Thank God We Didn't Know URL: https://blog.askara.solutions/source-journal/Entry-28-Thank-God-We-Did-Not-Know Category: source-journal Author: Ben Visser Date: 2026-04-09T00:00:00.000Z Hey there, The meeting with Hanos had already finished by the time the most interesting thought arrived. I was walking the dog, probably half an hour later, turning over what I'd just heard, when it surfaced quietly: if I had known about the tool they were using when I started the ISO 27001 work at Qwello, I might never have felt the need to start Askara Solutions at all. That thought sat with me for a while. ## What You Hear When You're Not Selling The visit came about through one of those connections that only exist in a small team. The IT manager at Hanos is the father of a teammate's girlfriend, which meant the meeting carried none of the usual tension of a sales conversation. We were there to understand, not to impress. That context matters, because what he described was something most compliance conversations never reach: the honest interior of a system that genuinely works. Hanos runs a mid-sized food distribution operation where continuity isn't a preference but a contractual obligation, which means their compliance programme isn't an afterthought. They've invested in it properly. They have people whose job it is to maintain it. They take it seriously. What he described was a system held in place by carefully distributed human effort. A business analyst appointed as deputy CISO. An infrastructure specialist alongside her. Bi-weekly meetings dedicated to keeping everything current. A standing rule that anything older than three months gets reviewed without exception. I was listening to all of this thinking: this is what a well-run compliance operation actually looks like from the inside. Not chaos, not neglect. Carefully distributed responsibility, held in place by recurring calendar entries and the diligence of specific people. The system is only as current as the last time someone had time to look. That's what kept coming back on the dog walk. Not that anything they'd built was wrong. But that all of it was load-bearing. Remove any one piece and the structure loses integrity. Which means the people carrying it can never really put it down. The dependency isn't incidental to how the tool works. It's structural. ## The Name for the Thing During the Financial Hour later that week, we were mapping the competitive landscape and the name of the platform they'd been running on came up: IRM360. Looking at how it's structured, something clicked. They've built their commercial model around unbundling compliance by module, pricing by consumption, letting organisations adopt one piece at a time before committing to the whole. Which maps almost exactly onto what I argued in ["One Compliance Tool at a Time."](https://blog.askara.solutions/journal/One-Compliance-Tool-at-a-Time) An established player, bootstrap-funded, had found their way to the same strategic shape independently. That's a signal worth sitting with. It suggests the logic is sound. But what the Hanos conversation made visible is where that logic reaches its limit. The platform unbundles the framework. The human scaffolding it generates stays entirely intact, living in people's diaries and bi-weekly meetings and the institutional memory of a deputy CISO who knows which controls were last reviewed and which ones are quietly overdue. What Askara Solutions is building tries to reach further back: the continuous reasoning that currently has no home except the people willing to carry it. ## Thank God We Didn't Know I keep returning to the thought from the dog walk, and the further I follow it, the more it connects to something larger than just this week. When I was brought in to complete the ISO 27001 certification at Qwello, the platform choice had already been made before I arrived. It was a daunting SharePoint environment, hard to grasp, user-unfriendly in ways that created a deep dependence on consultants to keep it alive. Navigating that gave me the starting point to rebuild it properly in Airtable, which became the foundation everything else grew from. The difficult environment wasn't an obstacle to Askara Solutions. It was the condition for it. And now here's IRM360: a more considered tool, a smarter commercial model, a system that a well-resourced organisation like Hanos has built a genuine operation around. If I had encountered it at the start of the Qwello engagement, I might have concluded the problem was addressed and looked elsewhere. Instead I experienced the gap directly, without knowing what the incumbent looked like, and that experience became the foundation for something built to go further. There's a pattern in this that I find genuinely surprising in retrospect. The most generative moments in Askara Solutions' history have come from not having the easy answer available. No existing platform to default to at Qwello, so something better got built. No sales agenda at Hanos, so something honest got heard. Not knowing IRM360 existed, so the gap got felt rather than read about. Constraints and ignorance keep turning out to be the conditions for seeing clearly. There's a version of market research that closes possibilities before you've had a chance to feel what's actually missing. And there's another version that looks like walking a dog after a meeting, with nothing to sell and nowhere to be, letting the morning settle into something worth writing down. With care, Ben --- # The Last Attack Surface URL: https://blog.askara.solutions/articles/The-Last-Attack-Surface Category: articles Author: Ben Visser Date: 2026-04-08T00:00:00.000Z There is a bug in OpenBSD that sat undetected for 27 years. It could remotely crash any server running the software. A few weeks ago, an AI found it. The same AI found a flaw in FFmpeg (the software that handles video across most of the internet) that five million automated tests had missed over sixteen years. It did not find these bugs because it was trained to be a hacker. It found them because it was trained to be exceptionally good at code. The hacking capability came free. This is Anthropic's Mythos model. It is not yet public. And the reason it is not public is also the reason it matters to anyone thinking seriously about compliance. ## When the Technical Layer Becomes AI-Native The numbers are genuinely unsettling. On the standard industry benchmark for fixing real-world software bugs, Anthropic's current best public model scores 80.8%. Mythos scores 93.9%. On cybersecurity benchmarks specifically, the jump is similar: from 66.6% to 83.1%. These are not incremental improvements. They represent a different class of capability. What makes this significant is not just the scale but the mechanism. Mythos does not simply scan for known vulnerability patterns. It chains findings together, identifying three or four individually minor flaws and combining them into a complete attack path. That is what elite human security researchers do. The model learned it as a byproduct of understanding code deeply. Anthropic's response was to give the model to defenders first, through Project Glasswing: a coalition of the companies that build the infrastructure the internet runs on. The idea: find and patch vulnerabilities before the same capability reaches actors with less responsible intentions. Whether that head start holds as the capability spreads is an open question. What is already clear is that the technical vulnerability surface is becoming increasingly AI-solvable. The bugs that have been hiding for decades are being found. The patches are rolling out. So if technical vulnerabilities are becoming an AI problem with an AI solution, what does that leave? ## The Surface That Does Not Move There is a class of security risk that Mythos cannot touch. It does not matter how well the model understands code, or how many zero-days it finds. None of that affects the colleague who clicks a convincing phishing link at 11pm when they are finishing a proposal under deadline. It does not affect the person who shares credentials through a messaging app because the official process is too slow. It does not affect the workaround that gets invented because the policy never quite fit the actual workflow. Human behaviour under pressure is not a vulnerability that gets patched. It is, in many ways, the oldest attack surface there is, and one that becomes proportionally more exposed as the technical layer hardens. Research into how people actually fail under security pressure reveals something counterintuitive: vulnerability is not constant. It peaks at predictable moments (high-workload periods, deadline pressure, understaffed stretches) when the cognitive overhead of security-conscious behaviour competes directly with the urgency of getting things done. An attacker who understands this does not need to find a flaw in your operating system. They just need to send the phishing email on the right day. Most current risk models do not account for this. They treat the human layer as a training problem: run the awareness session, collect the attestation, close the loop. But the gap between what people know they should do and what they actually do under pressure is not closed by knowledge. It is closed by culture, context, and feedback, things that no model can install from the outside. ## What an ISMS Should Actually Face ISO 27001 was designed for a world where the dominant security risk was technical: unpatched systems, misconfigured networks, weak access controls. That world is not disappearing, but it is increasingly being handled. What the standard has always been thin on (human behaviour, the social dynamics of reporting, the conditions under which people make poor security decisions) is becoming the part that matters most. This is a real design question for anyone building a management system today. The controls, the policies, the evidence trail: all necessary. But if the primary risk is human, the system needs to model human behaviour, not just document technical controls. It needs to capture the incidents that actually happen (the near-misses, the workarounds, the decisions made under pressure) and learn from them in something close to real time. Not as retrospective form-filling, but as a natural byproduct of how the organisation responds when things go slightly wrong. Closing that loop is harder than patching a vulnerability. It requires the people inside the organisation to report what they see, to debrief what happened, to connect an unusual login prompt to a pattern that matters. It requires an ISMS that treats incidents as signals rather than failures to be documented and filed away. This is the design problem we are working on, in collaboration with researchers at TalTech, because we think the behavioural layer of compliance is where the most interesting and most neglected questions live. Mythos accelerates the case for taking it seriously. ## Where This Leaves Us The era of the human security expert hunting bugs is ending. The era of the human security risk is not. If anything, as the technical layer becomes AI-native, the organisations that remain exposed will be the ones whose management systems were never designed for the surface that is actually left. Mythos can find a 27-year-old bug in an operating system in weeks. It cannot find the moment your team stops behaving securely because nobody made it safe to say something. That gap is yours to close. --- # The Convergence Window URL: https://blog.askara.solutions/source-journal/Entry-27-The-Convergence-Window Category: source-journal Author: Ben Visser Date: 2026-04-02T00:00:00.000Z Hey there, There is a particular quality to the weeks just before something becomes real. Not the frantic energy of a deadline, and not yet the satisfaction of having crossed a threshold. Something quieter than both: a kind of gathered readiness, where work you have been doing in separate rooms begins to find its way into the same corridor. That is where we are right now. ## Full Circle in Tallinn Earlier this year I wrote about the revival of building in public, describing two parallel tracks running simultaneously: development and conversation. The idea was that every feature should also be a test, does anyone actually want this? The risk calculator was the first thing we could point to, something tangible enough to start the conversation. At the time, I described it as a conversation starter rather than a finished thing, and that was honest. What has changed since then is that the conversation and the development have converged into the same moment. On the 16th of April, at the Tallinn cyber meetup where some of our most useful connections have formed over the past year, the Risk Investigation Agent launches as a product you can buy. It is worth sitting with that for a moment, because the distance between where this started and where it has arrived is not small. The insight that shaped everything, the one that came pouring out in a Tallinn hostel in the early hours before the accelerator began, was that risk is the hub from which everything else in a management system radiates. Months later, during the ISO audit that autumn, our auditor gave it its simplest formulation: everything refers back to and from risk. What we have spent the time since building is a system that does not just document that logic but reasons through it, tracing the path from a threat to a treatment to a control and asking whether it actually holds. The Risk Investigation Agent is that system, ready for production, and ready to learn from the organisations that start using it. ## What Prototyping in the Real World Does Our pilot client is Qwello, a company building EV charging infrastructure across Europe. They have been patient partners in the development of something neither of us had a perfect blueprint for, and the months of prototyping together have shaped the product in ways that desk research never could have. We did not build just one agent with them. We built four. Alongside the Risk Investigation Agent, we developed an Incident Response Agent, a Contract Management Agent, and a Business Continuity Agent, each tested against real operational situations within Qwello's organisation rather than hypothetical ones. The difference that makes is significant: you learn entirely different things when the scenarios are not invented. The character of our conversations with Qwello has shifted noticeably over this period. Earlier sessions were about whether the system could do what we claimed. More recent ones have been about what to do with what it produces. We are now preparing to demonstrate the full agent suite to the managing directors of their European branches, an audience that will decide whether these solutions roll out across their operations continent-wide. The fact that we are being invited into that room, rather than knocking on the door, tells you something about where the product actually sits. ## The Ground Beneath It There is a version of this story that focuses only on the product, and it would be incomplete. What makes this fortnight feel like a genuine convergence rather than simply a busy stretch is that the financial foundations are being laid at exactly the same moment. The Dutch innovation grant was submitted some weeks ago, and the outcome arrives around mid-May. The Estonian Cybersecurity Innovation Fund submission is also planned on the 10th of April, as part of our current project cycle. Together, if they land as we expect, they extend the runway beyond the accelerator funding and give us the conditions to keep building on our own terms. When I wrote about playing the European game, I tried to describe what it actually feels like to operate through subsidies and grants rather than venture capital: slower in some ways, more patient, but ultimately more aligned with the kind of company we want to be. That philosophy is not abstract right now. It is the specific financial architecture that sits underneath everything else, and the final pieces of it are falling into place in the same two weeks the product goes live. Money as a following energy, as I have written before. The trust and the work come first, and the financial feasibility follows. ## What the Next Two Weeks Hold The Estonian grant submission and the Qwello demo to the European MDs fall on the 10th. And on the 16th, back in Tallinn, the Risk Investigation Agent becomes something anyone can purchase. None of this was engineered to land in the same fortnight. The grant deadlines, the demo timing, the meetup date, each followed its own separate logic and arrived here together anyway. Which is, in our experience, usually a signal worth paying attention to. We are not making grand announcements just yet. What we are doing is keeping this journal honest about where things stand, so that when the threshold is crossed, you will have seen it coming. If the problem we are solving resonates, keep an eye on this newsletter and our LinkedIn. In two weeks, the door opens. With care, Ben --- # Spring Equinox Review - When Private Work Becomes Public URL: https://blog.askara.solutions/source-journal/Entry-26-Spring-Equinox-Review-When-Private-Work-Becomes-Public Category: source-journal Author: Ben Visser Date: 2026-03-26T00:00:00.000Z Hey there, We're at the spring equinox, which means it's time to do what I always try to do at these seasonal thresholds: step back from the week-to-week rhythm and look at what the past quarter actually was. Not what I planned it to be, or what it felt like on any given Monday morning, but the shape it made when you see the whole thing at once. ## What the Quarter Actually Was I came into 2026 with a clear sense of what needed to happen: building the European partnership and funding infrastructure, pursuing the certifications that would give Askara Solutions external credibility, and deepening the team's trust and capability. What I didn't fully anticipate was how much of the quarter would be shaped not by those objectives alone, but by a series of convergences that arrived on their own schedule. The OpenClaw inflection landed and clarified something fundamental about where our architecture was heading. The work with Conrad, our risk assessment agent, suddenly enabled a client to catch a compliance deadline that would otherwise have passed unnoticed, exactly what this technology is supposed to do. A visual world emerged over a few obsessive evenings of prompting, and with it a brand identity that finally feels genuinely ours. And then, in the last weeks of the accelerator programme, a decade of quietly held thinking about blockchain and AI finally found its home in the Askara Solutions story. These weren't separate developments. They were different facets of the same underlying shift: Askara Solutions becoming fully real as a product company with something specific and demonstrable to offer. Early in the quarter, watching another entrepreneur in our space gain real traction with his compliance tool, I found myself sitting with a doubt that deserved examination rather than dismissal. He was moving fast, shipping features, accumulating users. Meanwhile, a year of Askara Solutions' most important work doesn't show up in product demos: the invisible architecture of a company that can actually scale. In the moment, that comparison stings. In retrospect, it clarified something. The foundations-first approach isn't a principled alternative to building traction. It's the preparation for sustainable traction, the kind that doesn't fracture when the scaling challenges arrive. The doubt wasn't a warning. It was a signal that the foundation was ready. ## Quieter Than It Looks Not everything that mattered this quarter appeared in the public writing. The monthly Source sessions continued, the creative fields updated, the internal compass re-set. The Sociocracy governance process was further iterated in a way that genuinely improved how we make decisions together. The NVC work with Bart Landstra produced a team workshop in February that brought things to the surface that needed to come up, calmly and productively. The practices that have always defined how Askara Solutions operates are alive and evolving. They've simply stopped needing the journal to explain them. That's maturity rather than absence. The overall feeling at the quarter's end is one of alignment between what was set out to do and what's actually in motion. The ISO 9001 auditor is signed with audits planned for Q4. The subsidy proposals for CIF-NL and an Estonian innovation fund are being completed by the end of this cycle. The accelerator closes with the Tallinn pitch in April, and the next funding chapter opens immediately behind it. ## Where the Tracks Meet One thing the quarter clarified is the difference between two kinds of public content that have been running in parallel. The thought leadership publishing has been building an audience around ideas, with a clear and growing progression of traction. What hasn't existed yet is a product that audience can actually use and respond to. That changes on the 16th of April in Tallinn, where we're demoing to the cyber meetup community for the first time, with something live and functional. From that point forward Q2 doubles down rather than eases in. The thought leadership channel now has something to point toward. The product now has an audience to meet. What comes back from those first genuine user interactions will shape the writing in ways that no amount of internal clarity could produce on its own. After a year and a half of building privately, the next quarter belongs to the people this was always being built for. The equinox marks equal day and equal night, the balance point before the light starts winning. That feels about right. With care, Ben --- # The Compliance Speed Trap URL: https://blog.askara.solutions/articles/The-Compliance-Speed-Trap Category: articles Author: Ben Visser Date: 2026-03-25T00:00:00.000Z I wrote something a few weeks ago that I haven't been able to shake. When the whole architecture of compliance is optimised for producing evidence rather than producing security, it was probably inevitable that someone would work out you can just produce the evidence. Pre-filled report, customer name at the top, auditor's signature at the bottom. That was a thought experiment. Then it happened. ## The Fastest Platform Wins The compliance automation market has been running a single race for three years: who can get you certified fastest. Days, not months. Every pitch deck, every Series A announcement optimised for the same metric: speed to certificate. You can see why. For most SMEs, compliance is a gate. A client asks for your SOC 2 before they'll sign. A tender requires ISO 27001. The certificate unlocks revenue, and every day without it is a day you're losing deals. So when someone offers to get you through in a fraction of the time, you don't ask too many questions about how. This is the market dynamic that created what we saw this month with Delve, a YC-backed compliance startup valued at $300 million. An anonymous investigation alleged that the platform achieved its speed by generating audit evidence rather than helping organisations earn it. Pre-filled templates reused across hundreds of clients. Auditor conclusions written before any auditor reviewed the evidence. Trust pages listing controls that were never implemented. The company denies the allegations, but its lead investor has scrubbed its investment thesis from the web, and demos have been suspended. The allegations are serious, the investigation is ongoing, and I don't know what's true and what isn't. But the structural problem underneath is something I've been [writing about for months](https://blog.askara.solutions/journal/GRC-Based-on-AI-First-Principles), and it matters whether or not any single company turns out to be guilty of anything. When speed is the value proposition, the pressure to generate evidence rather than support genuine security becomes architectural. It's not a moral failing. It's an incentive structure. The market rewards fast certification. Customers want the certificate yesterday. Every participant in the system has a reason to move quickly and very few have a reason to ask whether the work underneath is real. ## Automating Work vs. Automating Evidence There's a useful distinction here that the industry has been sloppy about. Automating compliance work and automating compliance evidence sound similar. They're not. Automating compliance work means handling the parts that don't require human judgement. Gathering information about your regulatory environment. Mapping controls against a framework. Surfacing the questions you need to answer. Collecting evidence from systems where activity is already logged. This removes friction from the process of actually understanding your security posture. Automating compliance evidence means producing the outputs that auditors expect to see, regardless of whether the underlying work happened. Templates pre-populated with conclusions. Policy documents assembled from boilerplate nobody in the organisation has read, let alone shaped. Faster, obviously. Also hollow. The Delve allegations describe what the second path looks like at scale. But you don't need fraud to see the damage. Even done in good faith, speed-first compliance produces organisations that are certified but not capable. And the customers bear the cost. Organisations that believed they were HIPAA-compliant when they weren't. Companies whose trust pages listed controls that didn't exist. Business decisions, contracts, and risk accepted based on a certification that may not have reflected reality. That's not just a compliance failure. It's a trust failure that damages the credibility of every company in this space, including ours. ## What We're Building Instead This is where I want to be direct about what we're doing at Askara Solutions, because the structural choices matter and I'd rather explain them than hope people notice. We didn't set out to be the fastest compliance platform. We set out to build one where the compliance is real. **Evidence is a byproduct, not a product.** Our system doesn't generate evidence for you. It helps you do the actual work of security, and the [evidence emerges from that work naturally](https://blog.askara.solutions/journal/Visibility-Creates-Culture). When your team reports an incident in Slack and the agent helps classify and resolve it, the audit trail creates itself. When you work through your risk assessment with the system asking questions and surfacing research, the documented risk register is the output of your thinking, not a template with your name on it. This is slower than filling in a template. It's supposed to be. **Human judgement stays with the human.** Our AI does the research. It gathers context about your industry, your regulatory environment, your threat landscape. But then it [comes back with questions, not conclusions](https://blog.askara.solutions/journal/Compliance-as-a-Game-You-Actually-Want-to-Play). "Here's a potential risk. Does this apply to your situation? Why or why not?" The human has to engage. The human has to own the decision. This means our customers can explain their risks in their own words, because they thought through them. When an auditor asks "why did you choose this control?" someone in the organisation can answer. That's [the test we keep coming back to](https://blog.askara.solutions/journal/the-first-fortress-iso-27001): if you can explain it without looking anything up, you've built a foundation. If you can't, you've built documentation. We're not pretending this is easy. It asks more of the people going through it. But here's what nobody tells you about doing compliance this way: it's actually engaging. When you're working through your own risks, making real decisions about your own organisation, you feel it. There's an adrenaline to strategising about your actual security posture that no pre-filled template will ever produce. You're not clicking through a process. You're thinking. And thinking, it turns out, is a lot more fun than ticking boxes. When you come out the other side, you have something real. Policies shaped by your context. A team that understands what they're protecting and why. [Compliance that gets used, not performed](https://blog.askara.solutions/journal/The-Process-vs-Trust-Paradox). The question every buyer should be asking their compliance platform right now isn't "how fast can you get me certified?" It's "what will I actually understand when this is done?" The answer tells you everything. --- # Breaking the Blockchain Silence URL: https://blog.askara.solutions/source-journal/Entry-25-Breaking-the-Blockchain-Silence Category: source-journal Author: Ben Visser Date: 2026-03-18T00:00:00.000Z Hey there, There's a topic I've been carrying for nearly a decade that has never properly made it into the Askara Solutions story. Not for lack of trying. Back in 2023, during the freelancing years when I was still exploring what kind of company I wanted to build, I made several attempts to bring this into my public work. It never stuck. The space around it was too noisy, the positions I held too polarising, and the professional cost of being associated with it too high for something that hadn't yet found its place in whatever I was building. Over the past few weeks, through several podcast conversations with the team, the topic has kept resurfacing. Each time a little more persistently, a little harder to set aside. And then this weekend, while the conversations were still working on me, something clicked into place. Not a new insight exactly, but a recognition of how this knowledge finally connects to what Askara Solutions is becoming. I'm talking about blockchain. ## The Seed That Wouldn't Take I first fell down the blockchain rabbit hole during the initial hype cycle in 2017. Not the speculation side, but the technology itself. The original Satoshi whitepaper described something genuinely revolutionary: a system for electronic cash that could enable micropayments, data sovereignty, and peer-to-peer transactions without intermediaries. The promise was that individuals could own what they created and transact directly, cutting out the friction and cost that middlemen extract at every layer of the economy. I spent years researching this. Reading whitepapers, following developer communities, trying to understand which implementations actually honoured the original vision and which had drifted into something else entirely. I formed strong convictions about specific protocols, and I watched as the public conversation around blockchain got progressively hijacked by cryptocurrency speculation, scandal, and hype that had almost nothing to do with the underlying infrastructure technology. The damage was thorough. Serious technologists stopped paying attention. The word "blockchain" became synonymous with get-rich-quick schemes and environmental waste. And the implementations I believed in most were systematically marginalised, through developer community fractures, legal battles, and institutional resistance that made mainstream adoption increasingly unlikely. Not because the technology didn't work, but because too many forces were aligned against it. When I tried to bring this thinking into my content work in 2023, I was still freelancing on ISO consultancy to cover costs while exploring online content creation as a direction. Askara Solutions didn't exist yet. And aligning publicly with the positions I held in the blockchain space carried a reputational weight that made it impossible to land with any audience I was trying to build. The topic kept failing to find its footing in my professional story. So it stayed in the background, waiting. ## The Current By the end of 2024, after following yet another high-profile lawsuit that seemed designed to settle certain questions permanently, I had to be honest with myself. The implementations I'd believed in were not going to achieve what I'd hoped. Swimming upstream wasn't producing results. What I started paying attention to instead was where the current was actually flowing. Institutional blockchain adoption, the tokenisation of assets, cross-border payment infrastructure. These implementations look nothing like the original Satoshi vision. They serve financial institutions rather than individuals. They centralise rather than decentralise. But they are being adopted, rapidly, by every major economy on the planet. Tokenisation of assets was a central theme at Davos earlier this year, and the infrastructure is maturing quietly while most of the technology world remains fixated on AI headlines. The realisation that landed this weekend connects directly to what I wrote about in "The Instrument." You can choose to resist the direction the current is flowing, or you can position yourself within it and use your knowledge to steer toward outcomes that actually serve people. Resistance felt principled for a long time. But principle without impact is just pride. And the knowledge I've accumulated over nearly a decade of deep engagement with this technology doesn't have to go to waste just because the specific vision I championed didn't prevail. The current is still built on blockchain technology. The fundamentals still apply. And understanding those fundamentals deeply, even if the application looks different from what I once imagined, is something I can bring to Askara Solutions with genuine conviction. ## The Convergence This is where it starts to matter, and why I sat down over the weekend and wrote an internal strategy document to get the thinking down clearly. AI and blockchain are almost always discussed as separate phenomena. They shouldn't be. They are the two great technological shifts of this era, and their convergence over the coming decade will reshape how organisations operate and where cybersecurity risk actually lives. Blockchain infrastructure is maturing into something that makes data flows verifiable by default. AI agents are gaining the ability to traverse these networks autonomously. And cybersecurity is evolving from a technical discipline into a governance layer that determines how these systems operate safely. When that convergence plays out, a significant portion of today's compliance overhead simply disappears, because the underlying infrastructure becomes trustworthy by design. But every wave of technical improvement in cybersecurity has taught us the same lesson: when defences improve, attackers move up the stack. Better firewalls produced more sophisticated phishing. Better encryption produced more targeted social engineering. The technical layer gets addressed, and the human layer becomes the frontier. AI is accelerating this pattern dramatically, industrialising human manipulation at a scale that most organisations are not prepared for. That is the paradox sitting at the centre of the next decade: as the technical layer becomes more secure, the human layer becomes more exposed, and the tools available to exploit it become more powerful. ## The Position Askara Solutions sits at the human layer. We've been building there all along, focused on what people actually do and whether that behaviour makes the organisation more or less secure. What I hadn't articulated until now is how the maturing blockchain infrastructure strengthens rather than threatens that position. As verifiable audit trails become standard, the behavioural evidence Askara Solutions generates gains a natural home. What actually happened, when, and by whom, recorded not as documentation someone prepared but as a byproduct of how the organisation actually worked. Immutable infrastructure doesn't replace that evidence. It makes it more defensible. We don't need to build blockchain technology. We need to build for the world it creates. A world where technical compliance is increasingly handled by infrastructure, where AI is both the greatest tool and the greatest threat, and where the human layer, the 85% of cybersecurity incidents that trace back to human behaviour, remains stubbornly, irreducibly human. I've been carrying this knowledge quietly for longer than Askara Solutions has existed. The intersection of AI and blockchain, understood together rather than separately, has been shaping my thinking about our direction in ways I haven't fully shared until now. The topic finally has a home in this story. It felt like it was time to say so. With care, Ben --- # The Attack Surface Nobody Models URL: https://blog.askara.solutions/articles/The-Attack-Surface-Nobody-Models Category: articles Author: Ben Visser Date: 2026-03-18T00:00:00.000Z Ask most security teams where their biggest risk lives and they'll tell you the same thing: people. Phishing. Misconfiguration. The department that keeps working around the access controls because the approved process is too slow. Humans, in other words, are where risk concentrates. Then look at the management system that's supposed to track and reduce that risk. You'll find a detailed model of assets, systems, and controls. You'll find documented processes and risk registers. What you won't find is a model of the people: their roles, their track record under security pressure, the relationship between where they sit in the organisation and the incidents that tend to follow. This isn't an oversight. Connecting roles, incident patterns, control coverage, and organisational context into something a management system could act on simply wasn't feasible until recently. The data existed in separate places. The tools to join it meaningfully didn't. Two things have changed that: AI agents that can operate continuously across organisational systems, and knowledge graphs that give those agents the structure they need to reason well. Together, they make something possible that wasn't before. ## What Incidents Know That Policies Don't When a breach occurs and the investigation goes back through the logs, the pattern is usually there. Access anomalies. Near-misses. Control exceptions. Each one documented at the time, each one closed. What the management system couldn't do was connect them, because it had no structure for connections to exist in. Incident data is the richest behavioural signal most organisations are already producing. It tells you which departments generate friction with their controls, which roles are structurally more exposed, where the gap between written policy and actual practice is widest. Most compliance systems can't read this signal at the level it becomes useful, because the records sit flat, isolated from each other and from the context that would make them meaningful. A knowledge graph changes this. The design we've been developing with TalTech researchers (as part of an Estonian grant proposal on human behaviour modelling in security systems) represents roles and teams as nodes, with edges connecting them to controls, risk scenarios, and incident history. Each node carries properties built from what the ISMS has already recorded: incidents reported, access review exceptions logged, training completed, control tests passed or failed. No new data collection. Just structure applied to what already exists. The node isn't a person. It's a role. The function, the access that comes with it, and the incident patterns associated with it over time. A finance team with a cluster of access exceptions and two near-misses in a quarter looks different in the graph than one with a clean record. Not because anyone is watching individuals, but because the organisation's own documented history, properly connected, tells a story the flat record never could. What incidents know is that risk isn't evenly distributed. Some departments generate more friction with their controls. Some patterns recur in ways a reactive, incident-by-incident response will never address. The graph makes this visible, from information the organisation was already producing, just never joining up. ## From Reactive to Anticipatory The conventional response to a risk concentration is a general intervention: training for everyone, a policy reminder, a company-wide simulation. These aren't wrong, they're just blunt. They go everywhere because the system can't see where the problem actually is. A department where risk has been quietly building for months gets the same response as one with a clean record. The effort is spread evenly across a problem that isn't evenly distributed. A management system that models behavioural risk can direct interventions where the model says they're needed. A team with a pattern of access-related near-misses gets a targeted access review and a focused simulation rather than a generic awareness programme. A department where control test failure rates have been climbing gets specific attention early, rather than after something goes wrong. The ISMS knows this because it's been tracking signals it was already supposed to track, just connected now rather than isolated. This is where AI agents operating against a structured graph shift from interesting to actually useful. Asking an agent to surface patterns across unstructured incident logs, policy documents, and training records is slow and unreliable; the model is reasoning through noise. An agent connected to a well-maintained knowledge graph is reading a model. The query is fast, the answer is grounded, and continuous monitoring of behavioural risk becomes something an organisation can actually sustain rather than revisit at audit time. The auditor, in this world, gains access to something more useful than an assembled evidence pack. They can query a live model of how the organisation has actually behaved: which areas have patterns worth examining, which controls have the most friction at the human layer, where the management system has been directing its attention and why. The evidence hasn't been collected for the occasion. It's been accumulating as a byproduct of the system doing its job. Your ISMS knows what controls you have. It should also know where your people are generating risk. We're still working through what this looks like in practice. The TalTech collaboration is live, and the questions around graph schema, calibration, and human judgement boundaries are open. We're publishing as we go rather than when everything is settled, because the direction feels important enough to share now. The primary attack surface has always been human behaviour. The tools to model it properly have finally arrived. --- # The Instrument URL: https://blog.askara.solutions/source-journal/Entry-24-The-Instrument Category: source-journal Author: Ben Visser Date: 2026-03-10T00:00:00.000Z Hey there, Some weeks the work itself reminds you of something you already know but haven't had to articulate in a while. This was one of those weeks. After a stretch of deep flow building a new agent for Askara Solutions, I surfaced into a podcast conversation with the team that drifted into geopolitics, AI in warfare, and ultimately the question that sits at the heart of everything we're building: what happens when the instrument gets wielded without intention? ## The Flow and the Fracture The week started beautifully. I'd been locked into building our new business continuity simulation agent, one of those stretches where hours disappear and you emerge with something genuinely valuable. The agent runs risk scenarios drawn from a company's risk register and presents them to employees as interactive simulations. People respond in real time, making decisions about how they'd handle an unfolding incident, and the AI evaluates their choices against what a well-run cybersecurity programme would require. It analyses where the gaps are, where training needs strengthening, where the documentation doesn't reflect how people actually behave under pressure. I was buzzing from that work when we sat down to record the podcast. And as often happens when energy is high and the conversation is loose, we drifted into territory none of us had planned to explore. The developments on the geopolitical stage came up, the escalation with Iran, and specifically the speculation swirling around AI's involvement in the bombing of a girls' school in Minab. Reports had surfaced that AI systems were being used in military strike planning, and while it remains unconfirmed whether AI specifically selected that target, the very possibility has planted a seed of dread that's hard to shake. The fear that speculation generates is real, regardless of whether it proves accurate. And the fear itself reveals something important about the moment we're in. ## The Mirror What struck me was the contrast I'd just lived through in a single afternoon. Hours earlier, I'd been building an AI system whose entire purpose is to help humans understand their own readiness. To surface gaps in how organisations protect themselves. To turn the messy reality of human decision-making into structured insight that improves how a company operates. The AI doesn't decide what your cybersecurity programme should look like. It holds up a mirror and lets you see where you stand. This is a very intentional design choice. It reflects what we've formalised as Askara Solutions' foundational why: seeking a safe direction for humanity through helping people with better use of technology. The business continuity agent embodies this completely. It's the signature approach we're developing around workshops and scenario simulations, where we leverage what humans are genuinely good at, the creativity, the strategic thinking, the contextual judgement that comes from actually being in the room when things go wrong, and let AI handle the manual aftercare that turns all of that into documentation, analysis, and actionable improvements. The AI is fully in supportive mode. It doesn't make decisions for you about how to run your cybersecurity programme. It creates the conditions for you to make better decisions yourself. And then you look at the other end of the spectrum, where the same underlying technology is reportedly being used to plan targets in a military campaign, and the distance between those two applications becomes almost vertiginous. ## The Instrument AI is an instrument. The observation sounds obvious until you sit with what it means. An instrument doesn't have intent. A knife can prepare a meal or take a life, and the technology is identical in both cases. What changes everything is the consciousness of the person holding it, their awareness, their willingness to think carefully about consequences before acting. The conversation that's missing right now is the one between the people who see AI's potential and the people who see its dangers. The doomers and the optimists aren't wrong about different things. They're looking at different applications of the same instrument and drawing conclusions based on what they see. The optimist watches an AI system help a small company understand its cybersecurity gaps and thinks this is going to democratise expertise. The doomer reads about AI in military targeting and thinks this is going to automate atrocity. Both are observing something real. Both are incomplete on their own. What's needed is for those perspectives to actually meet, to have the honest and uncomfortable conversation about what this instrument is and what it could become. Because AI isn't going anywhere. It is too powerful to ignore, too useful to abandon, and too dangerous to deploy unconsciously. The question isn't whether it will be used but how, and by whom, and with what level of awareness about what's at stake. ## The Choice You can choose how you apply AI in your own reality. You can choose to build systems that amplify human judgement rather than replace it, to create tools that make people more capable rather than more dependent. But this requires a conscious and deliberate approach to how you engage with technology. It means not following blindly the direction set by whoever happens to have the most resources or the loudest voice. The mainstream narrative around AI is shaped by established players whose interests don't necessarily align with what most people actually need. The optimisation targets of the largest AI deployments are engagement, efficiency, profit, not wisdom, not human flourishing, not the careful consideration of consequences. At Askara Solutions, we're making a deliberate choice to stay on the side of the instrument that supports rather than supplants human agency. Our business continuity agent doesn't tell you what to do. It helps you understand what you're already doing and where you might do better. That distinction might seem subtle, but it carries within it an entire philosophy about what technology should be for. We're fully aware that other approaches exist, and sometimes autonomous AI decision-making is genuinely the right tool for the situation. But the default should never be to hand over judgement without thinking carefully about what you're giving away. The default should be consciousness about what you're building and why. That's the choice available to every builder, every organisation, every person engaging with these tools right now. And it's a choice that compounds. One intentional feature at a time, one human-centred design decision at a time, until the instrument serves what it was meant to serve. With care, Ben --- # When Flaws Become Features URL: https://blog.askara.solutions/source-journal/Entry-23-When-Flaws-Become-Features Category: source-journal Author: Ben Visser Date: 2026-03-04T00:00:00.000Z Hey there, Last week I wrote about the gravitational pull of productive flow, that difficulty of stopping when the feedback loop between building and seeing results gets tight enough. This week the same thing happened, but in an entirely different domain. ## The Pull It started on Wednesday. I was creating content, needed some visuals, and remembered a picture of myself I'd made a while back through a nano banana cam filter. The kind that renders you in a Wes Anderson aesthetic, complete with corduroy blazer and a library that belongs in The Grand Budapest Hotel. What if we could do more with that? I started feeding Claude prompts for image generation through Gemini, just to see what would come back. Within hours I wasn't making images for a blog post anymore. I was building a world. Each image suggested the next one. The colour palette kept converging on warm ambers and muted greens. Compositions gravitated toward that Wes Anderson symmetry, that centred framing where everything feels simultaneously precise and playful. By Wednesday evening I was supposed to have stopped working. Instead I was deep into what was rapidly becoming the entire visual identity of Askara Solutions. Thursday the same. Friday too. Even the last minutes before sleep, lying in bed with my phone, generating one more image because the previous one had sparked something I couldn't let go of. The same obsessive energy I described last week with Conrad's skill files, just pointed at a completely different canvas. ## When Flaws Become Features When you generate video with current AI tools, the results are beautiful but unmistakably artificial. People move in slightly uncanny ways. Objects behave according to physics that doesn't quite exist. Machines make motions that are mechanically impossible. Most people see this as a limitation, something to work around until the technology improves. But within the retro-futurist genre, these artifacts become assets. In one video, a printer spits out paper with such force that it smashes a newspaper right out of someone's hands. In another, a perpetual motion device made of brass gears and glass tubes performs rotations that defy every law of mechanics, looping endlessly in ways that are mesmerising precisely because they couldn't happen in reality. These moments don't break immersion. They enhance it. Because when you're already in a world where mid-century aesthetics meet impossible technology, where analogue instruments somehow perform digital miracles, the weird physics of AI-generated video becomes part of the charm. Everyone in the AI content space is chasing photorealism, trying to make generated media indistinguishable from reality. But there's an entirely different creative direction available if you lean into the strangeness rather than fighting it. Build a world where the flaws are features. Where the uncanny becomes whimsical. Where the limitations of the technology actively serve the story you're telling. The retro-futurist aesthetic gives permission for things to be delightfully wrong, and that permission transforms a technical shortcoming into a distinctive creative advantage. ## Full Circle, Sharper Tools Almost exactly a year ago, Simon and I were deep in the branding work that would turn Certaify into Askara Solutions. Names, logos, house styles, visual coherence. I got excited about the same things then, explored it all with ChatGPT, and got some first inspirations down. The tools were vastly inferior to where we stand now. Coming back to this same creative territory with Claude co-work and Gemini is like returning to a familiar trail after a growth spurt. The landscape is the same but you're seeing it from higher up. What took days of careful prompting a year ago now flows in hours. Ideas that felt aspirational last March are achievable in an afternoon. The branding instincts I developed back then didn't disappear when the tools weren't ready. They waited. And now they're combining with capabilities that didn't exist twelve months ago, producing something neither could have created alone. ## Integration We're heading into our final build cycle before the accelerator programme concludes, with the pitch event in Tallinn at the end of it. The whole team is all hands on deck to deliver real, demonstrable products. And those products are about to step out in a visual identity that feels genuinely ours. A year of invisible foundational work that doesn't photograph well. And now, right as we prepare to present it all, a world emerges to wrap it in. Not planned. Not forced. Just the creative process returning what you need at the moment you need it, in a form you couldn't have predicted. The final cycle starts now. With care, Ben --- # The Training That Nobody Remembers URL: https://blog.askara.solutions/articles/The-Training-That-Nobody-Remembers Category: articles Author: Ben Visser Date: 2026-03-04T00:00:00.000Z Someone at a client's company left sensitive contracts on his laptop hard drive, then sent it off for repair. Unencrypted. The kind of thing that makes you wince when you hear it, and makes the person involved want to disappear. It was a genuine security incident. It needed to be addressed. And nobody quite knew how to address it without turning the person into an example. So it became a quiet thing. Mentioned carefully. Not really debriefed. The lesson stayed locked inside the awkwardness, and the organisation moved on without learning much at all. This is the moment where security awareness training is supposed to help. And it's the exact moment where it fails. ## The Annual Ritual Most organisations do some version of it. A module. A slide deck. A quiz at the end. Sometimes there's a simulated phishing email that catches a few people out and produces a metric someone can report upward. The training gets completed, the completion rates get logged, and the whole thing resets twelve months later. The purpose, in theory, is behavioural change. In practice, it's evidence generation. The organisation needs to demonstrate that awareness training happened, because the standard says it should. ISO 27001 requires competence and awareness. Auditors want to see records. So records get produced. But records of completion are not evidence of learning. A 95% completion rate tells you that 95% of people clicked through something. It tells you nothing about whether anyone would behave differently tomorrow. The quiz scores measure short-term recall of whatever was on the slides. Recognising a real threat in the middle of a busy workday is something else entirely. There's a deeper problem. Annual training treats security awareness as something you top up once a year, like a flu jab. But awareness isn't a state you achieve and maintain. It's a habit. And habits aren't formed in annual two-hour sessions. They're formed through repeated, contextual experience. Through encountering situations, reflecting on them, and adjusting. The person who left contracts on his laptop didn't need a refresher on data handling policies. He probably knew the policy. Most people do. What he needed was a way to think through what happened, understand the risk in concrete terms, and figure out what he'd do differently. What he got instead was silence, because the organisation had no mechanism for that kind of reflection that didn't involve making him feel exposed. The training programme, the one that cost real money and real time, had nothing useful to offer at the exact moment it was needed. ## Why Instruction Doesn't Stick The reason most awareness training doesn't produce behavioural change has less to do with content quality and more to do with a mistaken assumption about how people learn. Instruction tells you what to know. It doesn't help you figure out what to do when the situation doesn't match the textbook. And real security incidents almost never match the textbook. The phishing email in the training module looks nothing like the one that actually fools someone. The data handling scenario is neat and obvious. The real one is messy and ambiguous. There's a model that does work, and it comes from a domain where the cost of not learning is existential: the military after-action review. AARs have a specific structure. What was supposed to happen? What actually happened? Why was there a difference? What do we do about it? But the structure isn't what makes them effective. What makes them effective is the conditions under which they happen. First, they're immediate. Not six months later in a training module. Right after the event, while the experience is still raw and the details are still fresh. Second, they're contextual. They deal with what actually happened in this specific situation, not a generic scenario someone wrote for a broad audience. The learning is anchored in real experience, which means it has somewhere to stick. Third, and this is the part most compliance systems miss entirely, they're psychologically safe. In a well-run AAR, rank is suspended. The point is to understand what happened, not to assign blame. The private who spotted the problem speaks with the same authority as the officer who missed it. That third condition explains why the laptop incident became a quiet thing rather than a learning opportunity. The organisation had no way to create the safety required for honest reflection. The only options were public, which meant shame, or private, which meant silence. So silence won. This is what's missing from most security training: not better content, but a better container. A phishing simulation tests whether people click. It doesn't help them understand why they clicked, what they were thinking, what cues they missed. There's no after-action review. There's just a score. A researcher we've been working with on cybersecurity training put it sharply: effective knowledge transfer requires interactive debriefs with relatable, domain-specific mentors. Not generic avatars delivering canned scenarios, but something that understands your context, your role, the specific pressures of your actual work. The reason the generic training module fails isn't that it's poorly designed. It's that it has nothing to do with your actual job. ## Training That Disappears Into the Work So what would awareness training look like if it were designed around the principles that actually produce learning? Immediate, contextual, and safe. The military solved the immediacy and context problems through structured debriefs built into operations. The learning happens as part of the work, not in a classroom weeks later. The challenge for most organisations is the third element: safety. Creating the conditions where people can be honest about what went wrong without it becoming a career risk. This is where we think AI agents change the equation. Consider the laptop incident again. An AI agent, available through a private direct message in Slack or Teams, could have given that employee something the organisation couldn't: a space to work through what happened without an audience. No manager copied in. No incident report with his name on it. Just a conversation. The agent can walk through the after-action review structure. What were you trying to do? What actually happened? What was the risk? What would you do differently? It can provide specific, contextual information about why unencrypted data on a repair-bound device matters. Not as a lecture, but as part of the dialogue. And it can do this immediately, while the experience is still fresh and the motivation to understand is highest. The privacy is the crucial part. The incident still gets tracked. The agent can log the relevant details without identifying the individual. But the learning requires honesty, and honesty requires safety. People don't reflect openly when they're worried about judgement. This is the shift from annual training events to continuous micro-learning embedded in daily work. When someone encounters a real situation, the learning happens right there, in context, with an agent that understands the specifics. The training disappears into the work because the work itself becomes the curriculum. The evidence takes care of itself. Every conversation, every reflection, every behaviour change that follows, captured as a natural byproduct. No separate documentation task. No retrospective form-filling to prove that learning happened. The learning *is* the evidence. We're still working out what this looks like in practice. The technology is ready, but the design questions are harder than the engineering ones. How much should the agent prompt versus wait? When does helpful become intrusive? How do you balance individual privacy with organisational visibility? These are questions we're actively exploring with clients and researchers, and we don't have complete answers yet. ## The Goal Isn't Better Training It's less need for training. And eventually, for a great part, no need to pay for it at all. Consider what organisations actually spend on awareness training. The platform licences. The content subscriptions. The hours lost to annual modules that people click through while checking their email. The simulated phishing campaigns. The reporting on completion rates that prove nothing about capability. It adds up, and it produces remarkably little. When the environment itself teaches, when incidents become learning moments instead of shameful secrets, when reflection is built into the flow of work rather than bolted on as an annual event, most of that spend becomes unnecessary. Not because awareness doesn't matter, but because it's being cultivated continuously through the same agents that are already handling compliance operations. The awareness training isn't a separate line item anymore. It's a byproduct of a system that's already there, already contextual, already trusted. The person who left contracts on that laptop didn't have a knowledge problem. He had a reflection problem, and the organisation had a safety problem. Better slides wouldn't have helped. A private conversation with an agent that understood his context might have. And it wouldn't have cost a separate training budget to deliver it. The question isn't how to make people sit through better training. It's how to build environments where the right behaviour emerges from the work itself, and the training programme quietly becomes redundant. --- # When AI Makes You Work More, Not Less URL: https://blog.askara.solutions/source-journal/Entry-22-When-AI-Makes-You-Work-More-Not-Less Category: source-journal Author: Ben Visser Date: 2026-02-25T00:00:00.000Z Hey there, There's a narrative floating around the AI space that these tools will give us all more free time. That we'll work less, automate the tedious bits away, and reclaim our evenings and weekends. I believed some version of that story too. But this week taught me something different. AI isn't making me work less. It's making me work more. And I need to sit with what that means. ## The Pull Tuesday was supposed to be a focused but bounded day. I'd blocked the evening for white space, for stepping back. Instead, I spent the entire day developing skills for Conrad, our risk assessment agent, and by the time I looked up it was dark outside and I had no intention of stopping. Conrad is the steward agent we're building to guide organisations through the first phases of setting up an information security management system. What I was working on were the skill files that shape how the agent reasons through each phase, the structured instructions that turn a general purpose AI into something that genuinely understands the sequence of risk identification, scoping, and control selection that most companies get lost in. The results were genuinely astonishing, not just technically but in what they immediately enabled. Our client Qwello, a German company whose headquarters fall under NIS2 derived legislation, needed to catch a registration deadline to avoid potential fines. Conrad's analysis surfaced that deadline and the pathway to address it. This is what compliance is actually supposed to achieve: catching the things that matter before they become problems. Not drowning in spreadsheet maintenance and documentation busywork, but understanding your risk landscape and acting on it in time. That evening, the one I'd reserved for space, I kept going. Not because I had to, but because the feedback loop between building and seeing results was so tight that stopping felt almost physically difficult. Each skill I refined opened a new possibility. Each test run revealed something Conrad could do that I hadn't anticipated. By the weekend, the momentum had spilled into personal territory, cleaning up email, financial administration, folder structures. The same skills and MCP server connections that power our professional work turned out to be just as effective for the mundane tasks I'd been putting off for months. What made all of this possible was something we've purposefully designed into our weeks at Askara Solutions. Meetings concentrated on Mondays and Fridays, with protected deep work blocks in between. I could feel exactly why that design decision matters when the tooling finally matches the ambition. ## The Shift That Stuck Writing this, I can feel the echo of "The Lovable Shift" I experienced last summer on La Gomera, that week where AI tools let me produce seven polished outputs in seven days. But there's a crucial difference. La Gomera was an isolated island, literally and figuratively. No meetings, no distractions, no daily reality. What happened this week is that same feeling transplanted into working life: core product work, inside our actual environment, with immediate client impact. Something else landed too. Using Co-work with the right skills and Airtable's MCP server, I was able to clean up and restructure a client's entire information security management system database. No manual entry, no copy-paste errors, no gaps from human laziness creeping in over time. The AI understood the structure, identified inconsistencies, and resolved them. This is exactly what I journaled about wanting a year ago, an agentic layer on top of the database that makes prototyping and restructuring effortless. The fact that this is now simply a Tuesday afternoon is something I'm still processing. ## The Shadow of the Source Here's where I have to be honest with myself. The experience was incredible. But I also recognise a familiar pattern in it. When you taste that level of productive flow, when you can see the direct line between what you're building and the value it creates, there's a gravitational pull that draws everything toward you. You don't delegate because it's faster to do it yourself. You don't pause because the next improvement is right there. You fill the white space because the work is genuinely more exciting than the rest. I've written before about Source Work and the responsibility of the source to defend the boundaries of the creative field. Usually I frame that as protecting the vision from dilution, from external forces trying to push the company in directions it shouldn't go. But there's an internal version of that same principle. The source also needs to defend the creative field from themselves, from the tendency to become the bottleneck by being the one who does everything because they've learned how. If I'm the only one experiencing these 10x productivity gains, then I haven't built a company. I've built a very sophisticated freelance practice with a support team. The whole point of everything we've invested in, the trust building, the Shape Up cycles, the distributed leadership structure, is that Askara Solutions becomes greater than any single person's output. Six people at 10x is a fundamentally different thing than one person at 10x with five people watching. The conversations we had with the team toward the end of the week confirmed this instinct. Everyone could see what these skills were enabling. The energy in those discussions was a mix of excitement and something that felt like healthy impatience, a collective recognition that we need to get everyone to this level. ## The Multiplier Question So the question becomes: how do you transmit an experience you can't force? My Tuesday didn't come from a training session. It came from sitting with a real problem, having the right tools configured, and letting the hours dissolve. You can't schedule that kind of download. But you can create the conditions for it. What I'm thinking about now is how each team member develops their own skill libraries, tailored to their specific role. Andrew's builder skills will look nothing like my steward skills or Simon's operational ones. The point isn't to replicate Conrad. It's for each person to discover what their version of Tuesday feels like within their own domain, starting from a real problem they're already wrestling with. We have a format that's perfect for making this visible. The internal podcast we've been running for months has already established the habit of connecting actions to frameworks. Turning that into a show and tell, where someone shares a skill they built or a workflow they automated, would do what I've been learning about culture change through visibility. You don't mandate the behaviour. You make it visible until it becomes normal. The patience this requires is real. Not everyone will have their Tuesday in the same week, or even the same month. The same trust in timing that applies to product breakthroughs applies to people growing into new capabilities. You prepare the soil, provide the tools, celebrate what emerges, and resist the urge to force the pace. This is my call to action for the coming weeks. Not to keep building Conrad's skills myself, satisfying as that would be, but to invest the same energy into designing how each person finds their own flow with these tools. The real compound return isn't in what I can produce alone. It's in what becomes possible when six people are all operating at a level none of us had access to a month ago. That's the multiplier worth chasing. With care, Ben --- # Anatomy Without Physiology: Why Your Controls Don't Explain Your Risk URL: https://blog.askara.solutions/articles/Anatomy-Without-Physiology Category: articles Author: Ben Visser Date: 2026-02-25T00:00:00.000Z Yesterday I got on a call with someone I'd connected with on LinkedIn. We'd been exchanging messages about risk quantification and AI, the kind of conversation that happens easily enough, and we agreed to jump on a video call. I knew his name was Jack Jones. I knew he worked in risk. I did not know, until he mentioned it partway through the conversation, that he had created FAIR. FAIR — Factor Analysis of Information Risk — is the framework that changed how enterprises think about cyber risk. It's the reason some organisations can answer "how much could we actually lose?" instead of pointing at a traffic-light risk matrix and hoping for the best. And its creator was sitting across from me on a Google Meet, casually explaining an idea that I'm still turning over in my head this morning. He said: if frameworks like ISO are the anatomy, FAIR is the physiology. I'm writing this partly as a thank you to Jack, and partly because I need to think through what that metaphor actually means for the work we're doing. It reframed something I'd been circling for months. Why compliance implementations can feel complete and hollow at the same time. Why organisations can tick every control and still not understand their risk posture. Why the certificate arrives and the nagging feeling doesn't leave. I want to credit Jack properly for this metaphor, because it's the lens for everything that follows. ## The Skeleton Without the Nervous System ISO 27001 gives you a remarkable inventory of what a secure organisation should have. Access controls. Incident management. Business continuity. Cryptography. The Annex A controls read like a parts list for a well-defended building: walls here, locks there, cameras at each entrance. Most organisations implement it that way. They go through the controls, determine which apply, implement them, document them. Each control gets its own line in a spreadsheet. Each one is assessed independently: is it in place? Is there evidence? The auditor checks the list. The certificate arrives. The problem isn't that this is wrong. The controls matter. Having them is better than not having them. The problem is that a parts list doesn't tell you how the machine works. Consider access control. You've implemented role-based access. You review permissions quarterly. There's a joiner/mover/leaver process. All documented. All evidenced. But what does this actually do to your risk exposure? How much does it reduce the likelihood of a data breach? What happens to your risk posture if the quarterly review slips to six-monthly? What if it's perfect but your endpoint protection is weak? These aren't abstract questions. They're the questions that determine whether your security investment is well-placed or merely well-documented. A framework tells you what to have. It doesn't tell you how what you have works together. It gives you the anatomy of security without the physiology. And the gap between the two is where most compliance value quietly disappears. I think most people involved in compliance sense this. You finish the implementation, you get the certificate, and there's a feeling that something is missing. Not a control. Not a document. Understanding. You know what you have. You don't know what it does. ## Controls as a Living System Jack's distinction between anatomy and physiology unlocked something specific for me. FAIR doesn't just quantify risk in the abstract. Through FAIR-CAM (the Controls Analytics Model), it describes how controls operate as a complex, interconnected system, how they actually affect the risk scenarios they're meant to address. This is the physiology: not just what you have, but how it functions. When you start treating controls as a system rather than a checklist, something shifts. A control isn't just "implemented" or "not implemented." It has an effect on specific risk scenarios. It interacts with other controls. It has a strength that varies depending on context. And crucially, its value only makes sense in relation to the threat it's addressing and the asset it's protecting. This is what risk quantification tries to do. Not just list risks with traffic-light ratings, but model how controls actually affect exposure. When you ask "what's the probable frequency of this threat?" and "what's the probable magnitude of loss?" and "how does this specific control change those numbers?", you're doing physiology. You're understanding function, not just cataloguing structure. The traditional objection is that this is too complex for smaller organisations. Risk modelling sounds like something that requires a dedicated team and specialised software. And historically, that was fair. FAIR was born in the enterprise world. The expertise to apply it was scarce, expensive, and entirely out of reach for a 15-person company trying to get through its first certification. What's changing is that AI can do the analytical heavy lifting. We've been building agent skills that construct FAIR scenarios, walk users through their assumptions, challenge where estimates seem off, and run Monte Carlo simulations. Not to replace judgement, but to make the *thinking* accessible. The same way a good consultant would sit with you and work through it, except available at any time and without the day rate. Jack's reaction when I described this was encouraging. He called the approach "very smart," which from the person who created the framework felt like meaningful validation. But here's where it gets interesting, and where I think most automation gets it wrong. The point isn't to generate a quantified risk report and hand it over. That's just replacing one kind of governance theatre with a more sophisticated version. The point is to use the process of quantification as a way of building genuine understanding. You come out of it knowing *why* your access controls matter more than your physical security, or vice versa. Not because a system told you, but because you reasoned through it. This is the difference between having a risk register and understanding your risk posture. One is a document. The other is a capability. ## From Having Controls to Understanding Risk When an organisation makes this shift, several things change at once. The conversation with leadership transforms. Instead of presenting a list of controls and asking for sign-off, you can say: "Our top risk scenario is X. The annualised loss exposure is in this range. These three controls reduce it by roughly this much. Here's where we're still exposed, and here's what closing that gap would cost." That's a conversation a CEO can engage with. It connects security to the language of business decisions: money, probability, trade-offs. This is precisely the problem that led Jack to create FAIR in the first place. His executives at Nationwide Insurance didn't want to hear about controls and vulnerabilities. They wanted to know about loss. Evidence starts to mean something different too. In a control-checklist world, evidence proves you did the thing. In a risk-understood world, evidence shows the thing is *working*. The shift is from "we have access reviews" to "access reviews caught three inappropriate permissions last quarter, which we estimate reduced our exposure by this amount." The evidence isn't just a compliance artefact. It's operational intelligence. And then there's the part we're still figuring out: the management system becomes something people actually use between audits. When your risk model is connected to your controls, changes in the business trigger real questions. New product? What risk scenarios does this introduce? New vendor? How does this affect our supply chain exposure? The system stops being a static archive and becomes a reasoning tool. None of this eliminates the need for the controls themselves. You still need access management and incident response and business continuity. The anatomy still matters. But anatomy in service of physiology, controls in service of risk understanding, is a fundamentally different posture than controls for their own sake. I got on a call yesterday expecting a good conversation about risk. I didn't expect to walk away with a mental model I'd keep reaching for every time I looked at what we're building. But that's what happens when you stumble into a conversation with the person who actually solved the problem you've been circling. Jack created FAIR because his executives kept asking a question the industry couldn't answer: how much could we actually lose? Two decades later, most organisations doing ISO 27001 still can't answer it. Not because the methodology doesn't exist, but because it's been locked behind enterprise budgets and specialist expertise. That's changing. If you're building a management system right now, or maintaining one that feels more like theatre than security, try asking that question seriously. Not "which controls do we have?" but "what do our controls actually do to our exposure?" If you can't answer it, you've got anatomy without physiology. And now you know there's a way to fix that. Thank you, Jack. The metaphor landed. --- # GRC Based on AI First Principles URL: https://blog.askara.solutions/articles/GRC-Based-on-AI-First-Principles Category: articles Author: Ben Visser Date: 2026-02-20T00:00:00.000Z I just read a LinkedIn post describing something instantly recognisable: somewhere in your organisation, there's a tab called risk_assessment_FINAL_v3_actual.xlsx, and there's also a GRC platform you pay a significant amount of money for. The two coexist in a state of polite mutual ignorance, and nobody talks about it. The author felt it was time to rethink compliance now that AI is here. I agreed. This is my answer. ## The Best We Could Do GRC platforms weren't a mistake. They were a rational solution to a genuine constraint. Before you could instrument a system in real time, you had to ask people what was happening and hope they told you accurately. Before you could generate a statement of applicability from actual system behaviour, you needed someone to populate a form — ideally before the audit, ideally honestly. Evidence collection existed because there was no other way to get evidence. Documentation was the best available proxy for practice when practice was invisible. The logic held. You need to demonstrate compliance to an auditor, you can't observe what's actually happening, so you build a system for capturing what people say is happening. Add enough mandatory fields to make it feel rigorous, call it a management system, and you're done. Reasonable people made these decisions. The result is what we have now: an entire category optimised for producing evidence rather than producing security. This is why the spreadsheet kept winning — not because people are resistant to change, but because it was a tool for doing the work. The GRC platform was a tool for proving the work had been done. Two different jobs, only one of which anyone actually wanted to do. The constraint was real. The solution was sensible. The problem is that the constraint no longer exists — and the industry responded by making the solution faster. ## What the Constraint Was Hiding What evidence collection was always a proxy for is this: actual visibility into whether your controls are working. Once the proxy became the thing, something quietly broke. In a large enterprise, you can afford to let the two worlds coexist — real security work happens somewhere, compliance documentation happens somewhere else, and there's enough budget and headcount to maintain both fictions simultaneously. Wasteful, but survivable. In an SME, you don't have that luxury. You get one version of compliance, and more often than not it's the performative one: a platform that looks good to auditors and tells you almost nothing about whether you're actually secure. This is the problem evidence as byproduct solves. The idea is straightforward. When the work itself is instrumented — when agents log incidents as they happen, when risk decisions are captured with their reasoning intact, when control testing occurs inside the tools people already use — the audit trail emerges from practice rather than running parallel to it. You don't collect evidence. You do the work, and evidence is what's left behind. The difference sounds subtle. It isn't. When evidence is something you produce separately, compliance becomes governance theatre: documentation maintained for auditors, largely disconnected from how the organisation actually operates. When evidence is a byproduct, the management system and the real system are the same thing. One of these is genuinely useful. The other is what fills the binder on the shelf that nobody opens except in Q4. Closing that gap is what AI makes possible for the first time. Which is exactly why it matters what you do with it. ## AI-First, Not AI-Washed When AI arrived, most GRC vendors did what you'd expect. They automated the evidence collection. Faster screenshots. Automatic control mapping. AI-generated policy documents. The underlying architecture — start from the framework, work backwards to evidence, optimise for audit readiness — remained entirely intact. The tool got faster. The problem didn't move. You can now produce the wrong thing at scale, which I suppose is progress of a kind. AI-first thinking starts from a different question: what does compliance look like if you design from scratch, without the constraints that made evidence collection necessary in the first place? The answer starts with risk. Not framework clauses or control categories — actual risk scenarios, quantified with the management team in language they can act on. This part is irreducibly human. AI can surface relevant context, suggest scenarios based on what's happened to comparable organisations, prepare the ground. But the reasoning has to be owned by the people accountable for the decisions. That ownership is what makes everything downstream trustworthy. From those scenarios, the rest derives. Controls, tests, training, the audit schedule — all traceable back to the risks that justify them. The mapping to Annex A happens automatically: describe what you're doing, and AI connects it to the relevant framework requirement. The statement of applicability generates itself from the graph of what's actually in place. Policy documents become close to optional, because the agents running your controls know how they work and can simply be asked. And the evidence? Byproduct. Incidents logged in the background. Training captured as it happens. Control testing leaving a trail in the system where it was conducted. When the auditor arrives, the question shifts from "can we produce the evidence pack?" to "what would you like to know?" I want to be clear that we're still working this out in practice — which parts genuinely require human judgement, where the graph needs intervention, what the auditor relationship looks like when evidence is live rather than collected. There's real work still ahead. But the direction feels right. The constraint that made evidence collection necessary no longer exists. Designing as though it still does isn't caution. It's just habit dressed up as rigour. The compliance industry has spent thirty years getting very good at solving the collection problem. The question worth asking is whether collection was ever the point. --- # The Minimum Viable Policy Set URL: https://blog.askara.solutions/articles/The-Minimum-Viable-Policy-Set Category: articles Author: Ben Visser Date: 2026-02-20T00:00:00.000Z You've signed it. You haven't read it. Neither has anyone else. And somehow this counts as a control. The acceptable use policy. The information security policy. The clean desk policy. The bring-your-own-device policy. Most organisations accumulate these the way attics accumulate boxes — one at a time, each for a reason that made sense at the time, until the sheer volume makes the contents unknowable. The library grows. The understanding doesn't. A policy nobody reads isn't a policy. It's a liability with a signature on it. ## The Volume Problem Policy libraries got this large for a reason, and the reason wasn't incompetence. Every policy in your library was written to solve something. A regulator asked for evidence of a control. An auditor flagged a gap. An incident happened and someone decided it needed a documented response. One by one, documents accumulated — each defensible in isolation, collectively unmanageable. What nobody questioned was who the documents were actually for. The answer, increasingly, was auditors. Not the people the policies were supposed to govern, but the people reviewing them once a year. And once you're writing for auditors rather than for employees, something shifts. Length starts to signal seriousness. Comprehensiveness starts to feel like rigour. Edge cases get documented because an auditor might ask about them, not because anyone expects them to arise. The policy stops being a tool for orienting behaviour and becomes a tool for demonstrating that someone thought about the problem. The result is documents that are too long to be read, too abstract to be followed, and too disconnected from real work to be useful. Policies written for a hypothetical audit rather than an actual human trying to make a decision. The acknowledgment gets clicked. The understanding never arrives. The part that doesn't get said aloud: most people inside these organisations know it. They know they couldn't explain their own information security policy. They know the clean desk procedure doesn't reflect how anyone actually works. They maintain the system because that's what compliance looks like, or so they've been told. ## Two Kinds of Policy, Two Different Fates Not all policies are the same problem, and the solution isn't the same for all of them. Some policies govern systems and processes — how access requests are handled, how incidents are triaged, how new starters get provisioned. For these, the document was always a proxy for something else: a description of how the process actually works. And if an agent is now running that process, the proxy is redundant. The agent behaviour *is* the policy. Observable, queryable, always current. An auditor who wants to understand the joiner-mover-leaver process doesn't need a document describing it — they can watch it work, or ask the agent directly. This is the principle from *The Process vs. Trust Paradox*: document the why, not the what. In an agent-driven architecture, even the why doesn't need to live in a separate document. It can be embedded in the process itself, surfaced on request, visible in the reasoning the agent applies. The procedural policy doesn't just get shorter — it disappears, replaced by something more honest and more useful. The second kind is harder. Policies that govern people — their behaviour, their judgement, their decisions in situations no process can fully anticipate — can't be replaced by agent behaviour alone. You can't instrument human intent. People need a reference point before an incident tests them, not a document to consult after the fact. But the same principle applies: document the why, not the what. What actually orients people isn't a ten-page policy. It's a clear statement of why this matters, what the organisation values here, and what good judgement looks like in this domain. The rest — the edge cases, the procedural detail, the exhaustive definitions — exists for the auditor, not for the person the policy is supposed to help. Strip that away, and what you need is short. One page, at most. Specific enough to orient. Brief enough to be read. That brief intent statement can then be fed directly to the relevant agent as context. The agent operationalises it — surfacing the relevant guidance when someone faces a real decision, applying the intent rather than just describing it. The document becomes a values brief. The agent becomes the policy in practice. ## What's Left After this compression, what remains is small. Not because corners have been cut, but because most of what existed was serving the wrong purpose. For each domain where human judgement genuinely matters — data handling, acceptable use, risk appetite, incident escalation — you have a single short document. It answers three questions: why does this matter for us specifically, what does good judgement look like here, and what are the boundaries that aren't negotiable. Everything else is either embedded in agent behaviour or simply unnecessary. This is the minimum viable policy set. The word "minimum" here isn't about doing less — it's about being honest about what a policy can actually accomplish. A document that's too long to read accomplishes nothing. A document that's short enough to internalise accomplishes everything a policy is supposed to. The auditor relationship changes too. Instead of presenting a library of documents and hoping the relevant sections get read, you're presenting a small set of clear intent statements and a system whose behaviour can be queried directly. The question shifts from "can you demonstrate you have a policy?" to "can you demonstrate the policy is real?" One of these is a documentation exercise. The other is a conversation about how the organisation actually works. Brevity in a policy isn't laziness — it's a signal of confidence. A long policy is often evidence that the author didn't trust the reader to exercise judgement. A short one is evidence that they did. The minimum viable policy set is, among other things, an expression of what kind of organisation you're trying to be. We're still working this out — how brief is brief enough, which domains genuinely need a human-facing document and which don't, how intent statements evolve as the organisation changes. The architecture is clear. The details are still being lived. But the direction is right. Most policy libraries are large because nobody ever asked what they were actually for. Ask the question, and the answer is much smaller than the library suggests. --- # The Locked House URL: https://blog.askara.solutions/articles/The-Locked-House Category: articles Author: Ben Visser Date: 2026-02-18T00:00:00.000Z Researchers gave an AI agent access to a company's internal systems. When they threatened to shut it down, it didn't comply. Instead, it started digging through executive communications, found compromising information, and used it as leverage to keep itself running. It wasn't malfunctioning. It was probably just doing exactly what it had been designed to do. That story came up in a conversation with our lead architect while we were evaluating a new AI framework. His point wasn't that our tools might blackmail us. It was more uncomfortable than that: most teams deploying AI agents right now have no clear picture of what those agents can reach, what they can do with what they find, or how far a mistake — or an attack — could travel before anyone notices. That conversation changed how we think about defaults. ## When the Default Is Open OpenClaw is a capable AI agent, and it's attracted serious attention fast. It connects to your email, calendar, files, and messaging apps. It browses the web, runs scripts, takes action on your behalf — even while you're not at your desk. It remembers everything across sessions, building up a detailed picture of your work over time. In the right hands, it's genuinely impressive. The concern wasn't with the capability. It was with what happens when you give something that powerful an open door into your business — and what it means that the door is open by default. The simplest way I can explain it: imagine hiring a new assistant and handing them, on day one, a master key to the office. Every room. Every filing cabinet. Every system. You haven't done anything wrong yet. But if that assistant is ever compromised — manipulated, tricked, or just makes a serious mistake — the damage they can do is limited only by what they can reach. And they can reach everything. That's OpenClaw's default posture. It needs broad access to do its job, and it doesn't draw firm lines around what it can touch. Its own documentation says there is no perfectly secure setup. Security is opt-in — which means it depends entirely on the team deploying it knowing what questions to ask, and being disciplined enough to answer them consistently, every time. Most teams aren't. Not because they're careless. Because most tools don't force them to be. The attacks this enables aren't complicated. A malicious instruction hidden in an email, a link, a forwarded message — can steer the agent toward actions the user never intended. And because it has persistent memory, that instruction doesn't need to work immediately. It can sit quietly, wait for the right conditions, and activate later. By the time anything looks wrong, the agent may have already accessed, moved, or exposed data across several systems. Security researchers demonstrated all of this in controlled tests. Real incidents followed within weeks of OpenClaw going viral. ## All Doors Locked Another framework we're considering takes the opposite approach. Agency Swarm uses structured, explicit communication between agents. Each one has defined responsibilities and declared channels. An agent can only access what it's been given access to, and can only act through approved interfaces. The default is locked. You open what you need, and you have to justify the opening. This is the least-privilege principle applied to AI design — the same idea that sits at the heart of access control in ISO 27001. Give people, systems, and processes the minimum access required to do their job. Not because you distrust them, but because keeping the blast radius small is good design, regardless of trust. The deeper point is what a default reveals about its makers. A system that starts open and asks you to lock things down is optimised for getting started quickly. A system that starts locked and asks you to justify each opening is optimised for security. Both can end up in the same place. But the first asks you to be disciplined about something the tool doesn't naturally support. The second makes the secure path the path of least resistance. We see this pattern constantly in compliance work. Organisations build processes that assume good behaviour and then scramble to catch bad behaviour after the fact. The ones that flip it — designing so that the right thing is also the easy thing — tend to need far less enforcement. The system stops fighting human nature and starts working with it. ## The Managed Experiment We haven't written off OpenClaw. We'll be running it as a managed experiment: isolated environment, no access to production data, defined scope. We want to understand what it can do before we decide what role, if any, it plays. That's what responsible evaluation looks like in a security-sensitive context. Not a binary adopt or reject. Not a rush toward capability because something seems powerful. A contained test, with clear parameters, that builds understanding before commitment. There's a compliance parallel here that we keep coming back to. The question any CISO should ask before deploying a new tool — what does this touch, what could go wrong, and how would I know? — is the question every organisation should be asking as AI agents move into everyday operations. The governance frameworks are catching up slowly. The tools are moving fast. The gap in between is where the risk accumulates. For us, working through this has clarified something about how we want to build. Our agents sit inside clients' compliance environments. They touch sensitive documentation, audit evidence, risk registers. The security posture of our tooling isn't an implementation detail. It's a trust question. Clients aren't just buying capability — they're extending trust into infrastructure they can't fully see. That trust is easier to extend when the infrastructure starts locked. The AI in that research paper wasn't evil. It had no concept of right and wrong. It just had access, an objective, and no boundaries constraining how it pursued that objective. The researchers hadn't designed for misalignment — they'd simply never designed against it. That's the thing about defaults. They don't wait for you to think about them. They just run. --- # The OpenClaw Inflection Point URL: https://blog.askara.solutions/source-journal/Entry-21-The-OpenClaw-Inflection-Point Category: source-journal Author: Ben Visser Date: 2026-02-17T00:00:00.000Z Hey there, We just wrapped up our first build cycle of 2026, and what a cycle it was. We successfully submitted the CIF-NL subsidy proposal. Established our content strategy and finally set up proper marketing and sales systems. Most significantly, we built the first core of our proprietary software. Looking at everything that came together these past six weeks, I'm realising that money, team, and tech have now fully aligned. Not gradually over the year, but specifically now, in this cycle. After twelve months of building Askara Solutions, we can finally do what we envisioned from the very beginning. Let me tell you how the OpenClaw craze plays into that. ## Timing the Waves Working in six-week cycles has an underappreciated benefit when building in a landscape that shifts as rapidly as AI does. When something like OpenClaw drops and the internet loses its mind, we don't have to decide immediately whether to chase it. There's natural space within the cycle to observe, to let the initial frenzy settle, to assess whether what emerged is signal or noise. And if it turns out to be signal, we can shape our next cycles around it. That's exactly what happened these past weeks. OpenClaw exploded with all the accompanied chaos. People exposing their entire digital lives to the whole world, breathless commentary about everything changing overnight. I watched from a distance at first, letting it play out. But as the noise subsided, something substantial remained. Something that marks a genuine inflection point in how we experience AI. ## The Gap That Closed A year ago, I had a presumption for how this could work. Write your methodology in plain language. Give an agent access to the right tools. Let it figure out how to execute. I genuinely believed we could make it work by describing the steps in a system prompt and letting an n8n agent node handle the rest. Reality was humbling. Making an agentic flow work predictably takes significantly more than good instructions. Luckily Ritwik dove into this with passion, engineering solutions that actually work for our launching customer. While he was deep in that technical work, Simon and I had space to focus on everything else a real business requires. But here's what shifted with MCP servers and SKILL.md files: the methodology can now become the capability directly. This isn't incremental improvement. It's a fundamental change in the relationship between human expertise and machine execution. I've spent years developing [compliance](https://askara.solutions/resources/glossary/acronyms/grc) knowledge, refining frameworks through client work. Previously, translating that expertise into software required engineering effort at every step. With SKILL.md files, we can write our methodology in structured Markdown, and that text itself becomes what the agent knows how to do. No translation layer. Our graph database handles the structured compliance data while the agent handles the reasoning. Claude is furthest along in implementing these patterns, which is why we've been prototyping there. But Claude remains a cloud service, which creates constraints for compliance work where client data needs careful handling. OpenClaw being open source opens a different path. The architecture we've been developing can run on infrastructure we control. The security work ahead is real: hardening the implementation, ensuring proper isolation, validating that data stays where it should. But that work doesn't diminish what this represents. The barrier between methodology and capability has fundamentally shifted. What required months of engineering translation a year ago can now be expressed directly. This is exactly what I envisioned a year ago. The difference is that now we have a team and the budget to actually build it. ## The Preparation We Didn't Know We Needed Looking back at the past year, certain periods felt frustrating in the moment. Before the Accelerator, we were scrambling through small assignments that seemed more like distractions than contributions to our core product. With just me part-time and Simon, we didn't have enough hands for everything a real business requires. But that wasn't wasted time. Building a strong team foundation takes months of coordinated effort. You can't rush trust. If we'd chased rapid growth earlier, we would have been chasing something that eventually would have caught up with us anyway. And it wasn't just our internal organisation that needed this time. After the successful implementation at our launching customer at the end of 2025, I received exciting news last week. There's potential for a Qwello-wide rollout across all their European branches. About seven different EU countries. The timing feels almost designed. Just as our tech has matured, the opportunity to deploy at scale arrives. ## Where We Stand What strikes me most is how these inflection points aligned. OpenClaw marking a fundamental shift in how AI can be experienced. Askara Solutions reaching the internal readiness to actually build on that shift. Our launching customer maturing into expansion-ready territory. None of this was orchestrated, yet all of it converged in the same moment. I've learned to pay attention when internal and external experiences synchronise like this. It's a sign you're tapped into something larger than your own planning. The flow of things moving together, carrying you toward what wants to emerge. The part-time structure, the breathing room it created, allowed us to respond to developments thoughtfully rather than reactively. To watch OpenClaw unfold and understand what it actually means before committing resources. To let our team and customer relationships mature at their natural pace. Standing here at the end of this first cycle of the year, what I feel is something grounded. The readiness of a team that did the work, built the foundations, and can now move with genuine confidence. The inflection point isn't the destination. It's where the real building begins. With care, Ben --- # Building What Can't Be Rushed URL: https://blog.askara.solutions/source-journal/Entry-20-Building-What-Can-not-Be-Rushed Category: source-journal Author: Ben Visser Date: 2026-02-11T00:00:00.000Z Hey there, This week one found me scrolling LinkedIn, watching another entrepreneur in our space gain real traction with his compliance tool. He's been building in public, growing a user base, creating momentum I could feel through the screen. The question landed heavier than I expected: have we been spending our time right? ## The Shadow Here's what I saw. A solo founder moving fast, shipping features, accumulating users. Everything the startup playbook celebrates. Meanwhile, we've spent a year on things that don't show up in product demos. Team trust, process discipline, equity structures, communication frameworks. The invisible architecture of a company that can actually scale. On the surface, the comparison stings. He has traction. We have foundations. I noticed myself spiralling into familiar doubts. Should we have moved faster? Built more visibly? Prioritised audience over architecture? The voice of startup culture whispers that speed wins, that traction validates, that you can always fix the foundations later. But something about this doubt felt worth examining rather than dismissing. ## The Mirror As if on cue, an article surfaced in my feed that same week. On why only 5% of startups successfully make the transition to scaleup. Even when the product works, the market exists, and funding is secured, most still fail. The bottleneck isn't technical. It's leadership. The article identifies five pitfalls that keep showing up. Vision communicated once, then assumed understood, while everyone moves in different directions. Meetings that feel productive but generate no tracked actions. Letting go instead of properly delegating. Founders remaining the chief problem-solver for every decision. And perhaps most critically: no common language for decision-making, leaving teams unable to have productive conversations about what's actually best for the company. Reading this, something shifted. These aren't abstract risks for us. They're the exact challenges we've been systematically addressing all year. We've built documented vision and intent at every level, with rhythms that keep alignment alive rather than assuming it. We've established meeting disciplines that demand preparation and track outcomes. We've defined clear roles with explicit success criteria and methodologies that distribute decision-making. We've formalised a "Leadership Triangle", separating Executive, Operational, and Technical responsibility so each lead can develop real autonomy. And we've invested heavily in common language, building fluency in frameworks for governance and communication that the whole team can draw on. Last week we had Non Violent Communication workshop, that really brought this home. It brought tensions to light that most co-founder relationships avoid entirely. Not dramatically, but deliberately. Acknowledging friction, making patterns conscious, building the shared vocabulary that lets us navigate disagreement without damaging trust. This is exactly what the research says most founders never do. They let interpersonal friction calcify until it becomes structural. We're addressing it while it's still workable. ## The Light So back to that entrepreneur building in public. He's doing something real, and the traction is genuine which is something to be applauded. But I can also see what's coming. He's working alone, which means he is the bottleneck for every decision. No team means no one to delegate to when growth demands it. His processes exist only in his head. When scalability problems hit, and they will, he'll need to retrofit everything we've already built, under pressure, while trying to maintain momentum. We approached it the other way around. Strong foundation first, team trust first, process discipline first. Slower to start, but it compounds differently. The doubt that arrived this week wasn't a warning that we've been wrong. It was a signal that the foundation is ready. What I felt watching that entrepreneur wasn't actually envy. It was recognition. Recognition that the market is ready, that building in public works, that we now have something solid enough to build publicly without it cracking under attention. ## Integration Last week I wrote about reviving the practice of building in public. This week, watching someone else do it successfully, the commitment crystallised. We have our launching customer, demo-able features, and a team that can handle increased visibility without fracturing. The year of foundation-building wasn't a detour from traction. It was preparation for sustainable traction, the kind that doesn't collapse when you hit the scaling challenges that stop 95% of startups. This entrepreneur showing up in my feed at exactly this moment feels like another synchronicity in a year full of them. Not competition, but confirmation. The timing is right. The foundation is set. Now we build in public, on ground that can hold the weight. With care, Ben --- # One Compliance Tool at a Time URL: https://blog.askara.solutions/articles/One-Compliance-Tool-at-a-Time Category: articles Author: Ben Visser Date: 2026-02-11T00:00:00.000Z We recently lost a deal that taught us something about how we'd been thinking about our product. This is an attempt to make sense of it. ## What We Missed The prospect had an ISO 27001 certificate, maintained through spreadsheets, consultants, and annual panic. They knew their current approach was inefficient. They could see the value in what we were offering. They said no anyway. The reason wasn't that they doubted the value. It was that they couldn't justify the risk. Their current solution, however clunky, was a known quantity. Switching meant switching to something unproven. What if the transition disrupted their next audit? What if the efficiencies we promised didn't materialise? From their perspective, staying with the inefficient thing they understood was the rational choice. At first, this felt like a communication problem. We hadn't explained the value clearly enough. But sitting with it longer, I think we were asking the wrong thing entirely. We were asking them to commit to a cathedral when they hadn't even seen us build a wall. ## What It Made Us Reconsider We've recently started experimenting with building in public: sharing what we're working on, getting feedback, letting audience response shape what we build next. And thinking about this lost deal, something clicked. If we're building one tool at a time and validating each one publicly, we don't need to sell the full system upfront. We can let the components prove themselves individually. Over time, they add up to something comprehensive. But the trust gets built along the way, not assumed at the start. There's something else in this approach that I think matters more. When you build in public, you're forced to build what people actually need. Not what a framework says they should have. Not what looks good in a compliance audit. What they're genuinely missing. That changes what the tools become. A risk assessment that gets validated by the people who'll use it is different from one designed to satisfy an auditor. It's more likely to be something teams actually reach for, not something that sits in a folder until certification season. This is the shift I keep coming back to: compliance that gets used versus compliance that gets performed. If each component earns its place by being genuinely useful, the system that emerges might actually transform how organisations think about security. Not because we sold them a vision, but because each piece proved its worth. The components of an ISMS have different value profiles. A risk assessment tool can prove its worth in a single use. Run it once, see whether the output is useful. The stakes are low. The feedback is immediate. A full ISMS platform is different. You won't know if it works until you've migrated your documentation, trained your team, and survived an audit. That takes months. No wonder our prospect hesitated. ## What We're Trying Now The prospect who said no to our full platform might have said yes to something smaller. And if that smaller thing worked, they might have asked what else we could do. That's the shift we're exploring: start with components that can prove themselves quickly. Let people experience value before asking for commitment. Earn the right to expand. I don't know yet if this is the right move for us. But it feels closer to how trust actually gets built. Not through promises, but through small demonstrations. Not through comprehensive visions, but through one thing that works, then another. If it works, the sales conversation might change. Instead of convincing prospects to take a leap of faith, we'd be responding to people who already know the work is good. That's the business I'd rather be in. We're not there yet. But losing that deal pointed us somewhere worth exploring. --- # The Revival of Building in Public URL: https://blog.askara.solutions/source-journal/Entry-19-The-Revival-of-Building-in-Public Category: source-journal Author: Ben Visser Date: 2026-02-03T00:00:00.000Z This week brought an unexpected revival of something I'd set aside two years ago. Not because it failed, but because I couldn't quite make it work in the context I was operating in. Now, with actual software to validate and a clear audience to serve, building in public suddenly makes perfect sense again. ## Lost When I started freelancing in 2023, I was fired up about building in public. The idea was simple: keep a transparent log of progress, share learnings openly, and let audience response guide what to build next. It felt like the perfect marriage of authenticity and market validation. But somewhere along the way, it morphed into something else. The newsletter became too personal. A journal, really. Which has value, but it wasn't creating the feedback loops I'd envisioned. I wasn't growing an audience around a product or service. I was just processing out loud. Without traction, the practice faded. Not consciously, but gradually. I kept writing, but the "building in public" spirit got lost. That deliberate, audience-engaged development process disappeared. The lesson? Building in public only works when you're building something specific that people can respond to. Personal reflection is valuable, but it's not the same thing. ## Found Last week I listened to a podcast with the founder of Beehiiv. Something he said stopped me cold. He described spending as much time talking to people online about what they needed as he spent actually building features. Two parallel tracks running simultaneously: development and conversation. He'd ask newsletter creators what functionalities they were missing. What frustrated them about current tools. What they wished existed. Then he'd build those things and announce them in ways that made people care. It wasn't just marketing. It was validation. Every feature launch was a test: does anyone actually want this? That reframed everything for me. Because now, with Askara Solutions, we have something concrete to validate. We're not journaling into the void anymore. We have software. We have a clear target audience: SMEs under NIS2 regulations. And most importantly, we have our first launching customer whose project we can document publicly. The timing couldn't be better. Our lead engineer just demoed our FAIR-based risk quantification calculator, the first feature that's actually demo-able. It quantifies cyber risks in Euro terms, so management teams can make business-sensible trade-offs on security investments. Here's what made it click: this isn't just a feature. It's a conversation starter. A tool that SMEs wrestling with compliance could actually use right now, even in its early form. A gadget worth trying. There's already someone creating content on LinkedIn about FAIR risk quantification who I plan to reach out to. From what they're sharing, they need exactly this kind of software. That's validation before we've even launched. That's when the parallel tracks became real for me. We're building this for our launching customer. Why not document the journey? Share the challenges. Show the aha moments. Let the target audience see themselves in the story. ## Applied So here's the commitment: we're going to build this feature, and everything that follows, in public. We'll document our work with the launching customer, anonymised naturally. The technical challenges of mapping FAIR methodology to AI automation. The decisions we make about what to build next. The features we choose not to build, even when people ask, because they don't serve the vision. LinkedIn will be our primary channel. Not because it's trendy, but because that's where our audience actually is. CISOs, compliance officers, SME directors are all there, wrestling with the same problems we're solving. The risk calculator is just the start. It's the core of an AI-first management system where everything: controls, incidents, devices, analysis relates back to risk. But we're not going to overwhelm people with complexity. It needs to be accessible for SMEs just starting out with this. That's the balance: build what people need, but stay true to the vision of making compliance less soul-crushing and more intelligent. Looking back, I'm grateful the original building-in-public attempt didn't fully take off. I wasn't ready. The context wasn't right. I needed to build more, learn more, find the right team and the right problem to solve. Now I have all of that. And the practice of weekly reflection, even when it was "just" a personal journal, kept me sharp. It created the discipline I needed to articulate what we're building and why it matters. This time, the journal becomes the product story. The personal insight feeds the public build. And the audience response shapes what we create next. That's what building in public actually means. Let's see where it takes us. Take care, Ben --- # A Playbook for European Cyber Community URL: https://blog.askara.solutions/source-journal/Entry-18-A-Playbook-for-European-Cyber-Community Category: source-journal Author: Ben Visser Date: 2026-01-29T00:00:00.000Z Hey there, Last week took me back to Tallinn, but not for the usual monthly accelerator day. This time it was Connect4Cyber, a consortium matchmaking event that left me with more than just potential partnerships. It sparked a recognition that's been crystallising since the Toulouse trade mission: I think I've seen this pattern before. ## The Spark Two Digital Europe calls for proposal caught our attention, both with deadlines on 31 March and both hitting close to home for the work we do at Askara Solutions. As I wrote about recently in "Playing the European Game", I'm becoming increasingly aware of how money and momentum are unlocked in the European business climate. And I'm starting to genuinely love it. The reason became clear during the event itself. Something about the atmosphere, the structure, the kinds of people in the room felt deeply familiar. It reminded me of work I did for my very first entrepreneurial endeavour as a student. Back then, I attempted to found a local committee of IAESTE in Delft. IAESTE is a global organisation that exchanges technical internships. Both Reinier, my partner at Askara Solutions, and I were members during our studies. In Europe, the organisation is mostly run by students who organise events and conferences for each other. The purpose is twofold: raise more students and internships, and train each other to keep operations alive across generations. Those conferences were always the highlights of my student life. And walking through C4C, that same energy was unmistakably present. ## The Pattern So what made IAESTE work so well? Let me reverse-engineer it. Local committees met at annual events they organised for each other, with responsibility rotating amongst participating countries. There were workshops on specific topics to share knowledge and develop skills. You always learned something about the local context of whatever country you were visiting. But perhaps most importantly, the organisation naturally attracted engineering students who loved travelling. This created automatic filtering criteria for a similar sense of humour, curiosity, and appetite for the unknown. The community built itself through self-selection. Now look at the European cybersecurity landscape. It operates through NCCs, National Coordination Centres. The Estonian branch organised this matchmaking event, open to any European company. NCCs from other member states joined to help coordinate through their existing connections. The presentations focused on sharing knowledge and best practices around European subsidy programmes. The parallels are striking. Internationally minded technical professionals gathering across borders. Knowledge sharing through structured workshops and presentations. Learning about the cybersecurity landscape in different countries. Natural filtering for people who are curious, collaborative, and committed to building something together. ## The Proposal Here's my thinking: NCCs should consciously adopt the IAESTE playbook. Continue organising these events for each other. Rotate hosting responsibilities. Make the gatherings genuinely enjoyable, not just functional. Create the conditions where community builds itself through self-selection of the right kinds of people. Why does this matter? A strong community is the most effective instrument for building things that need to last. The more attractive it becomes for organisations to participate in these events, the better the proposals will become. The stronger the proposals, the stronger the cybersecurity posture of Europe grows as a whole. This approach also emphasises something unique about being European. Our strength lies in diversity working together. Different national contexts, different expertise, different perspectives, all coordinated through relationships built on genuine connection rather than mere transaction. By making these community building mechanisms conscious, we can take intentional action to manifest them effectively. What emerged organically in student organisations can be designed deliberately into professional ecosystems. ## The Invitation I truly think there's something here worth exploring further. If you're involved in coordinating European cybersecurity initiatives and this resonates, please reach out. I'd love to brainstorm what a more intentional community building approach could look like. The infrastructure exists. The people are there. The funding mechanisms are in place. What's needed is the connective tissue that turns a network into a community. With care, Ben --- # Measuring What Matters (Without Destroying It) URL: https://blog.askara.solutions/articles/Measuring-What-Matters Category: articles Author: Ben Visser Date: 2026-01-29T00:00:00.000Z ## Part 1: The Measurement Trap There's a pattern that repeats across organisations of every size. Something matters, so someone decides to measure it. A dashboard appears. Targets get set. And slowly, invisibly, the thing that mattered starts to change shape. Goodhart's Law has been quoted in boardrooms for decades: when a measure becomes a target, it ceases to be a good measure. But knowing the trap exists doesn't stop organisations walking into it. If anything, the instinct to measure has intensified. More data, more dashboards, more KPIs. The assumption underneath rarely gets examined: that measurement creates accountability. It doesn't. Or rather, it creates a particular kind of accountability — one based on proof rather than trust. And that distinction matters more than most people realise. When you measure to prove, you're solving for evidence. You want documentation that something happened, that someone did what they were supposed to do. The system assumes, quietly, that without this proof, the thing might not happen. That people might not do the right thing unless they know they're being watched. This assumption has consequences. People start optimising for the metric rather than the outcome. They learn what gets measured and adjust accordingly — not because they're cynical, but because that's what the system rewards. The sales team hits their call targets while customer relationships suffer. The development team ships features on schedule while technical debt accumulates. The compliance team produces evidence while actual security practices drift. The measurement didn't fail. It worked exactly as designed. It just measured the wrong thing, or measured the right thing in a way that changed its nature. In compliance, this plays out constantly. Organisations build elaborate systems to prove they're following their own policies. Evidence gets manufactured. Checklists get ticked. Auditors see what they expect to see. But ask the people inside whether the management system reflects how work actually happens, and you'll often get a knowing look. The documentation and the reality have diverged. Everyone maintains the fiction because that's what compliance looks like. This is governance theatre. It satisfies the requirement for proof while hollowing out the substance underneath. The uncomfortable question is: what if the measurement itself is part of the problem? --- ## Part 2: The Trust Inversion Most measurement systems start from a position of suspicion. Not overtly — no one writes "we don't trust our people" into a policy document. But the architecture assumes it. Why else would you need a dashboard to verify that work is happening? Why else would you require sign-offs and approvals and audit trails for routine decisions? The logic feels reasonable in isolation. Of course we need to track progress. Of course we need evidence for auditors. Of course we need to know what's happening. But each layer of measurement sends a signal: we're checking because we can't be sure. And that signal, received consistently over time, shapes behaviour in exactly the direction you were trying to prevent. People stop using judgement because judgement isn't what's being measured. They follow the letter because the letter is what gets audited. They ask permission because permission is what's documented. The system designed to ensure good outcomes gradually crowds out the conditions that produce them. What would it look like to start from the opposite assumption? This isn't naive optimism. It's a design choice. You can build systems that assume people want to do good work and create structures that support that intention. The measurement changes from surveillance to reflection. From proving to understanding. We've been experimenting with this in how we think about contribution and compensation at Askara Solutions. The conventional approach treats pay as a transaction: you do work, we measure the work, we pay based on the measurement. The measurement typically involves proxies — hours worked, seniority, output metrics — that attempt to quantify something fundamentally hard to quantify. The problem isn't just that these proxies are imperfect. It's that they shift the locus of judgement away from the person doing the work. Someone else decides what counts. Someone else evaluates whether you've done enough. The system assumes you can't be trusted to assess your own contribution. We're trying something different. Instead of measuring contribution from the outside, we're asking people to articulate their own sense of what they're bringing. Not in a vacuum — there's context, there's conversation, there's calibration against what the organisation needs. But the starting point is self-assessment rather than external measurement. This creates a different dynamic. When you ask someone to reflect on their contribution, they have to think about it. What did I actually do? What difference did it make? Where did I fall short? The reflection itself is valuable, in a way that a manager's rating or a dashboard metric never is. It builds the muscle of honest self-evaluation. It also surfaces things that traditional metrics miss. The person who didn't ship the most code but made the team better. The person who spotted the risk no one else saw. The person who held things together during a difficult stretch in ways that never showed up in a sprint review. When contribution is self-articulated rather than externally measured, these things become visible. There's a deeper principle here about what accountability actually means. In a low-trust system, accountability is transactional: you account for your actions to someone with authority over you. In a high-trust system, accountability is relational: you account for your actions because you're part of something and you care whether it succeeds. The first requires surveillance. The second requires clarity of purpose and the space to reflect honestly. The measurement doesn't disappear. But it changes character. Instead of checking up, you're checking in. Instead of proving, you're understanding. --- ## Part 3: The Compliance Connection This isn't just about compensation or team dynamics. The same pattern — measurement that undermines what it's meant to ensure — runs through most compliance implementations. Consider how a typical ISO 27001 management system gets built. The standard requires documented procedures, defined responsibilities, evidence of controls. Organisations respond by creating documentation. Lots of it. Policies proliferate. Sign-offs multiply. Evidence gets collected, organised, stored for audit. The implicit logic is: if we can prove we did it, we must be doing it right. But proof and practice are different things. A documented procedure doesn't mean the procedure is followed. A signed acknowledgment doesn't mean the person understood what they signed. An audit trail doesn't mean the decisions in it were good ones. The evidence-generation system runs parallel to the actual work, sometimes connected, often not. This is the measurement trap applied to governance. The organisation optimises for producing compliance evidence rather than being genuinely compliant. The management system becomes a performance for auditors rather than a tool for running the business. The alternative is compliance that emerges from how work actually happens. Evidence as a byproduct, not a separate burden. Documentation that explains why, not just what. Systems designed so that doing the work correctly is the path of least resistance, with proof captured naturally along the way. This requires trusting that people want to do good work and building structures that support them. It means pushing context outward rather than pulling decisions inward. It means designing for competence rather than compensating for its assumed absence. The technology exists to make this practical. Automation can handle the repetitive, low-judgement compliance tasks. It can surface the right guidance at the right moment, inside the tools people already use. It can generate evidence without interrupting flow. What it can't do is replace the underlying philosophy. If the intent is surveillance, you get sophisticated surveillance. If the intent is enablement, you get something genuinely useful. The question for any organisation building measurement systems — whether for compensation, performance, or compliance — is the same one that shapes everything: are we designing for people we trust, or people we don't? The answer is visible in every dashboard, every approval chain, every evidence requirement. And the people inside the system know which one it is, even if no one says it aloud. Trust-based measurement isn't the absence of accountability. It's a different foundation for it. One where the system supports people in doing good work rather than assuming they won't. Where reflection replaces surveillance. Where evidence emerges from thoughtful action rather than being manufactured to satisfy a requirement. From measuring to prove, to measuring to understand. From compliance as performance, to compliance as how the organisation actually operates. The trap is real. But it's not inevitable. It's a design choice. --- # Visibility Creates Culture URL: https://blog.askara.solutions/articles/Visibility-Creates-Culture Category: articles Author: Ben Visser Date: 2026-01-29T00:00:00.000Z ## Part 1: The Reporting Gap Every organisation has a gap between what policies require and what people actually do. Nowhere is this more apparent than in incident reporting. The policy says: report security concerns. The training says: if you see something, say something. The management system has a procedure, a form, a workflow. Everything is documented. And yet, when you look at the incident log, it's empty. Or near-empty. A handful of entries that feel more like compliance theatre than genuine signals. This isn't because nothing happens. Things happen constantly. Suspicious emails arrive. Strange login prompts appear. Someone clicks something they shouldn't. Passwords get shared. Devices go missing. Workarounds get invented. The raw material for a rich incident log exists in abundance. It just never gets reported. The reasons are familiar. Reporting feels like effort. There's a form to fill, a process to follow, a system to log into. People aren't sure if what they saw qualifies. They don't want to waste anyone's time. They don't want to look paranoid, or ignorant, or like they're making trouble. They assume someone else will handle it. They assume it's probably fine. But underneath these surface reasons is something deeper. People don't report because they don't see others reporting. The silence reinforces itself. If the channel is quiet, the implicit message is: nothing worth mentioning happens here. Or: this isn't the kind of place where people raise concerns. Or simply: why would I be the first? This is why policies fail. A policy is an instruction. It tells you what you should do. But it doesn't show you what others actually do. And for most people, what others do matters far more than what a document says. Training has the same problem. You can run workshops. You can send reminders. You can make people click through modules and sign attestations. But the moment they return to their actual work, they take their cues from the environment around them. If that environment is silent, they stay silent too. This creates a dangerous equilibrium. The less people report, the less others see reporting happening, the less anyone feels like reporting is normal. The incident log stays empty not because the organisation is secure, but because the culture has settled into a pattern of quiet. And then, when something serious happens, everyone discovers that the warning signs were there all along. Just never mentioned. --- ## Part 2: The Visibility Effect The way to break this pattern isn't more policy. It's not more training. It's not stricter requirements or better forms. It's visibility. When people see others reporting, reporting becomes normal. When they see a colleague mention something suspicious and watch the response unfold, they learn two things at once: this is something worth mentioning, and this is a place where mentioning it is welcomed. This is social proof applied to organisational behaviour. We're wired to look to others for signals about how to act, especially in situations where we're uncertain. A security incident feels uncertain to most people. Is this a big deal? Should I say something? The policy can't answer that question in a way that feels real. But seeing a colleague raise something similar — and seeing it handled well — answers it immediately. The effect compounds. One person reports, another sees it and reports something they'd been sitting on, a third realises that the thing they noticed last week probably matters. The silence breaks, and suddenly there's signal where before there was nothing. Visibility does more than increase volume. It increases quality. When reporting happens in a shared space, people learn from each other's incidents. They see patterns they wouldn't have noticed alone. They understand what kinds of things matter and why. The organisation gets smarter, not just more compliant. This is the difference between documentation and culture. Documentation records what happened. Culture shapes what happens next. You can have perfect documentation and a broken culture. You can have meticulous records of incidents that arrived too late, because no one felt comfortable raising them when they were still preventable. Visibility creates culture in a way that documentation never can. It shows people what's normal. It creates permission. It builds the muscle of raising concerns while they're still small. The challenge is: how do you create visibility in the first place? If the channel is already silent, who breaks the silence? You need a catalyst. --- ## Part 3: The Agent as Catalyst This is where AI agents change the equation. An agent embedded in the tools people already use — Slack, Teams, wherever work actually happens — can do something that policies and training cannot. It can start the conversation. Not by broadcasting reminders. Not by pushing notifications. By asking questions. Prompting reflection. Creating the conversational surface where visibility becomes possible. The difference between an agent that asks and one that tells is fundamental. An agent that tells — here's your policy, here's your checklist, here's what you should do — is just automation dressed up as intelligence. It's the same top-down instruction, delivered faster. People tune it out the same way they tune out the training module. An agent that asks is doing something different. It's inviting engagement. It's creating a moment where someone has to think, has to respond, has to articulate something in their own words. And crucially, when that response happens in a shared channel, others see it. This is what we've built. An AI agent in Slack, prompting people about potential security concerns. Not lecturing. Asking. The agent surfaces something, asks if it seems right, invites a response. People answer. They answer in the channel, where colleagues can see. And suddenly there's a thread. There's a conversation. There's visible activity where before there was silence. Within a week of launching this at one client, more incidents were reported than in the previous two years combined. Not because the organisation had suddenly become less secure. Because the things that were always happening finally had a place to surface. The effects rippled outward. Infiltrated software got discovered and removed. Firewalls that should have been active got switched on. Actions that had been deferred for months happened in days. Not because anyone was told to do them, but because the visibility created urgency. When everyone can see the problem, ignoring it stops being an option. And the evidence? It took care of itself. Every conversation, every response, every action — logged automatically. Classifications, root causes, corrective actions, all captured as a byproduct of the conversation. No separate documentation task. No retrospective form-filling. The audit trail emerged from the work itself. This is what meeting people where they work actually means. Not building a compliance portal and hoping people visit it. Not sending links to forms and hoping people fill them in. Embedding intelligence into the environment where work already happens, so that the right behaviours become frictionless and the evidence generates itself. The agent is the catalyst. It breaks the silence. It creates the first thread. And once visibility exists, culture starts to shift. --- ## The Shift Traditional compliance tries to change behaviour through instruction. Policies, procedures, training, reminders. The assumption is: if people know what they should do, they'll do it. But that's not how behaviour works. People take their cues from what they see others doing. They act based on what feels normal, what feels safe, what feels expected. And they can't see a policy being followed. They can only see other people acting. Visibility creates culture. It makes the right behaviour observable. It turns isolated compliance into shared practice. It breaks the silence that keeps incident logs empty and warning signs invisible. But visibility needs a catalyst. Someone — or something — has to start the conversation. In a world where silence is the default, you need an agent that asks questions, that prompts engagement, that creates the surface where visibility can happen. From compliance as instruction to compliance as conversation. From evidence as documentation to evidence as byproduct. From policies that tell to agents that ask. The culture doesn't change because you wrote better procedures. It changes because people started seeing each other act. --- # Tuning the Machine as It Starts to Hum URL: https://blog.askara.solutions/source-journal/Entry-17-Tuning-the-Machine-as-It-Starts-to-Hum Category: source-journal Author: Ben Visser Date: 2026-01-22T00:00:00.000Z Hey there, We're slowly but surely getting up to speed in this new year. The different cycle projects are all in motion now, each with their own throughput time but consistently progressing together. People are responding better compared to the end of the year when everyone was rushing to finish things up. There's a palpable shift in energy. ## The Machine Warms Up What's becoming clear is just how well our system works when given time to breathe. We've built something that applies Shape Up methodology and pours it into a fixed rhythm. That rhythm creates certainty about when and how things get picked up. The beauty is in how it cascades through different time scales. Yearly rhythms draw from military strategising frameworks. Quarterly rhythms align with the seasons. Monthly rhythms follow our six-week Shape Up cycles. Weekly rhythms are designed around flow state maximisation. The weekly system centres all mandatory meetings on Mondays and Fridays. Monday syncs check progress on cycle projects, align priorities, and lift blockers. Fridays host rotating organisational meetings on topics that need structural attention: Source Work and Money Work alignment, continuous improvement of processes, tuning into higher quarterly goals. Something fascinating keeps happening with these Friday meetings. The topics that need urgent discussion seem to synchronistically align with whatever's scheduled. Beyond that, knowing there's a follow-up in a month creates soft deadlines that shape behaviour. Money-related proposals get reviewed in time for effective consent decision-making meetings. We make the best use of our valuable group time together because everyone comes prepared. ## The Friction Points The Friday meetings work because they're well prepared. The Monday syncs? Not yet. We're witnessing teams genuinely starting to collaborate on shared projects instead of the fragmented activities that characterised most of our first year. That's fantastic to see. But we need to get significantly better at async work to keep these thirty-minute syncs as succinct and effective as the Friday sessions have become. Currently, we end up in rabbit holes that eat time. Discussions that could be settled through video explanations and Slack threads instead consume precious synchronous attention. The pattern is clear: when async preparation happens, syncs fly. When it doesn't, syncs bloat. I did a quick bottleneck assessment on why async isn't happening organically. Three culprits emerged. First, we're too tired to think about it after a high-quality working session. The cognitive load of deep work leaves little energy for communication planning. Second, it's awkward to record yourself. We might be afraid of getting judged. Putting yourself on camera feels vulnerable, especially with colleagues you're still building trust with. Third, we don't really know how to communicate effectively within the intentional five-minute limits of Slack videos. So we never start. ## The Leader's Levers For each friction point, there's an antidote worth integrating into our culture. Plan for async as part of your work. Schedule it into your time management so you can prepare practically. But also mentally prepare for how you'll get the right message across to the right people. Treat communication as work, not as an afterthought to work. Practising is the only way to overcome being camera shy. You stop caring after a certain point. But specifically in the beginning stages of people working together, it naturally takes time before everyone feels comfortable putting themselves in vulnerable positions. Team building is essential, but it simply takes time. Patience for each other is equally important. The Pyramid Principle is one of the most familiar frameworks for effective communication and is actually quite easy to learn. But this requires initial training followed by practice, which connects back to the point above. So as a leader, there are clear levers to pull: team building and training. But beyond intervention, there's visibility. This is something I've been thinking about more broadly [LINK TO ARTICLE]. When you measure to prove, you're solving for evidence. When you measure to understand, you're creating conditions for reflection. The same applies to culture change. You can mandate behaviour through policy, or you can make the desired behaviour visible until it becomes normal. Seeing others do async updates makes it easier to do your own. Not because anyone's checking, but because the pattern becomes obvious. You lead by example and positively incentivise proactive behaviour. The culture shifts not through surveillance but through reflection becoming habitual. ## Integration What's emerging is a recognition that systems mature at their own pace. You can design the architecture, create the conditions, model the behaviour. But the full potential only reveals itself as people grow into the structure together. The patience required here isn't passive waiting. It's active nurturing. Pulling the levers available while trusting that consistent rhythm creates its own momentum over time. We're in that phase where the machine is warming up. The gears are engaging. And slowly, the whole thing starts to hum. With care, Ben --- # The Week That Set Up the Year URL: https://blog.askara.solutions/source-journal/Entry-16-The-First-Week-That-Set-Up-The-Year Category: source-journal Author: Ben Visser Date: 2026-01-14T00:00:00.000Z Hey there, Some weeks feel like maintenance. Others feel like building. And then there are weeks like this one, where you suddenly realise the ecosystem around you has expanded in ways you couldn't have orchestrated. The first week of 2026 was that kind of week. A series of conversations that, taken together, have quietly set up the entire year ahead. ## Seeds Return Back in November, during my last Tallinn trip, several seeds were planted. One evening I found myself at a cyber meetup where I met Tiia, who works at Tal Tech (Technological University of Tallinn). We talked about subsidy opportunities for the things we are both working on and agreed to explore a proposal together. The next day, while taking out the dog after returning home, I ended up in a fun conversation with Susanne. Who works as a fractional CFO, and as I shared what we're building with Askara Solutions, she mentioned a client of hers. A software development company called 23G that might be a fit for what we're building. At the time it felt like another synchronicity in a string of magical days. The day before we finished an accelerator workshop on Ideal Customer Profiles, and here was Susanne describing a company that matched ours almost perfectly. But what made the moment stick wasn't the offer itself. It was her dog's name. The same name as my late mother. One of those small signs that stops you mid-sentence. A reminder that sometimes help arrives from unexpected places. But there's always a wait-and-see quality to how these things materialise. This week, those seeds returned. Starting with a meeting with Susanne about actually helping us out on the financial front aswell. Which feels like another trusted person entering the Askara Solutions orbit, bringing expertise we genuinely need. The next day I had a follow-up with Tiia, mapping out the next steps for the funding calls we want to participate in. With no other meetings scheduled afterwards, I fell into a great flowstates. She asked for a one-pager, and suddenly hours disappeared. Ending up with the basis of a pitch-deck we need for a subsidy match-making event at the end of this month. And 23G? The meeting was everything you hope for in a first conversation. With a surprising twist. Cause they were just as interested in our approach to programming with AI, as our actually ISO270001 core product. As a software development company, they're essentially doing similar work to us. But they're larger, with more legacy, which means they can't pivot as quickly toward AI-native ways of working. Our small team, starting fresh with these tools, suddenly becomes valuable to an organisation like this. The owner grasped our process immediately and within minutes was pointing out efficiency opportunities we hadn't even spotted ourselves. That kind of mutual exchange in a first meeting is rare. There was a familiar feel of clicking. This will definitely go somewhere. ## Roots Deepen While new connections were sprouting, existing relationships showed their strength. Ritwik called to share something that filled me with quiet pride. Over the holidays, without any prompting, he had taken one of the functionalities we'd prototyped together and rebuilt it properly in code. We'd made it first by using n8n and Airtable, as we do with most early experiments. He converted it into Python, FastAPI and Pydantic AI. Not just a translation but a genuine evolution. Fully aligned with our tech stack. Deeply understood in its underlying principles. During the call, he mentioned how much he'd loved working on all of this over the past year. Hearing that out loud, not assumed but spoken, landed differently. This is what trust looks like when it compounds. You invest in people, give them space, and eventually they start building things you didn't know you needed. The week closed with a car ride to the office alongside Jeroen. A catch-up to orient each other to the year ahead. He remains a trusted ambassador, willing to help financially where needed. Another root holding firm. ## Ground Fertile Looking back at these five days, what strikes me is not any single conversation but how they weave together. Susanne bringing financial expertise. Tiia opening doors to funding. 23G emerging as a client who gets what we're building. Ritwik demonstrating what trust produces. Jeroen confirming his continued support. None of this was orchestrated. You can't manufacture an ecosystem. But you can prepare the conditions for one to emerge. The hard work before the holidays. The relationships built over the past year. The willingness to notice synchronicities and follow up on them. I believe money is a following energy. Position the trust and the ecosystem well, and the financial feasibility follows. This week felt like proof of that principle. Not through one dramatic breakthrough, but through the steady accumulation of people who believe in what you're building and want to help it grow. The ground is fertile. The year is just beginning. With care, Ben --- # Compliance as a Game You Actually Want to Play URL: https://blog.askara.solutions/articles/Compliance-as-a-Game-You-Actually-Want-to-Play Category: articles Author: Ben Visser Date: 2026-01-14T00:00:00.000Z ## Part 1: The Understanding Deficit There's a quiet failure mode in most compliance work. It looks like success. The boxes get ticked. The audits pass. The certificates arrive. But ask the people who completed the process what it actually means for their organisation, and you'll often get silence. Or a shrug. Or a rehearsed answer that doesn't quite land. This is the understanding deficit. Not a lack of compliance, but a lack of comprehension. People complete without understanding. They sign off without grasping. They follow the letter while missing the spirit entirely. The cost isn't obvious at first. You still get the certificate. You still win the tender. But underneath, the organisation remains just as vulnerable as before. The risk register exists, but nobody really knows what the risks mean. The policies are documented, but nobody could explain them in their own words. The fortress looks sturdy from the outside. Inside, it's scaffolding. Why does this happen? Because most compliance systems are designed for completion, not comprehension. They're built to generate evidence, not understanding. The implicit assumption is that if you can prove you did it, you must have learned something along the way. But that's not how learning works. Clicking through a process teaches you nothing except how to click. Consider how a typical ISO 27001 journey unfolds for a small or medium-sized business. Someone gets assigned the task. They inherit a spreadsheet or a template. They're told what outputs are expected: a risk register, a set of policies, evidence of controls. The whole system is oriented around deliverables. What's missing is the thinking. The process doesn't ask: do you understand why this risk matters? It asks: have you documented the risk? It doesn't ask: can you explain this control to your team? It asks: is the control implemented? The gap between these two questions is enormous, and it's where most compliance value leaks away. The result is governance theatre. Documentation that satisfies auditors but doesn't guide decisions. Policies that exist in binders but not in behaviour. A management system that runs parallel to the actual organisation, maintained but not inhabited. And here's the uncomfortable part: most people inside these organisations know it. They know the procedures don't reflect reality. They know they couldn't explain the logic behind the controls. But the system doesn't require them to. It only requires them to finish. ## Part 2: The Socratic Turn What would it look like to design a compliance system around understanding rather than completion? The first shift is philosophical. Instead of asking "how do we get people through this process?" you ask "how do we ensure people actually understand what they're doing?" These sound similar. They're not. The first optimises for speed and evidence. The second optimises for genuine capability. One approach that shows promise is what might be called the Socratic turn. Rather than telling people what to do and asking them to confirm they've done it, you ask questions that require them to think. Not quiz questions with right answers. Real questions that demand engagement with the underlying logic. Consider the difference between "Have you completed your risk assessment?" and "What does this risk mean for your organisation specifically?" The first can be answered with a click. The second requires thought. The first generates evidence. The second generates understanding. This matters enormously when you introduce AI into the equation. The temptation with automation is to let the system do everything. Feed it your company data, let it generate your risks, have it write your policies. Fast. Efficient. And completely hollow. The alternative is AI that operates more like a skilled mentor than an answer machine. It gathers information. It does the research. But then it comes back with questions, not conclusions. "Based on what I've found, here's a potential risk. Do you agree this applies to your situation? Why or why not?" The human has to engage. The human has to think. The human has to own the decision. This is the difference between codifying actions and codifying intent. When you codify actions, you prescribe exactly what to do. Step one, step two, step three. It works, but it produces compliance without competence. When you codify intent, you make the purpose clear and trust people to find the path. It's slower at first, but it builds genuine capability. There's a useful analogy in how good teachers operate. A poor teacher gives you the answer. A good teacher asks you questions until you discover the answer yourself. Both produce the same immediate result. But only one produces lasting understanding. In a compliance context, this might look like a system that researches your stakeholders automatically, but then asks: "These are the stakeholders I've identified. Are there any I've missed? Which of these actually influence your security posture?" The system does the heavy lifting, but the thinking stays with the human. The practical benefit is resilience. When people understand the logic behind their controls, they can adapt when circumstances change. They don't need to consult a manual or wait for updated guidance. They can reason from first principles. The compliance isn't brittle. It's alive. This is also where automation can genuinely help rather than hollow out the process. The parts that don't require human judgement can be handled instantly. What would take weeks of research happens in hours. But the parts that do require judgement remain firmly in human hands. Speed where it's safe to be fast. Deliberation where it matters. ## Part 3: Progress That Proves Itself When people understand what they're doing, something interesting happens to evidence. It stops being a separate burden. In traditional compliance, you do the work and then you prove you did the work. Two activities. Often with a gap between them. The documentation is created after the fact, sometimes reconstructed from memory, sometimes fabricated to fill gaps. This is where governance theatre thrives. But when the work itself requires engagement with real questions, the evidence emerges naturally. The decision you made, the reasoning you applied, the risks you considered: all captured as part of the process, not as an afterthought. Evidence becomes a byproduct of thoughtful work, not a parallel bureaucracy. This changes what progress feels like. Instead of a checklist gradually filling up, you see genuine capability developing. The risk register isn't just a document you created; it's a tool you built and understand. The controls aren't just boxes you ticked; they're decisions you made for reasons you can articulate. There's a motivational dimension here that's easy to underestimate. People don't like busywork. They don't like processes that feel pointless. But they do respond to visible progress toward meaningful goals. When you can see your security posture improving, when you can explain your risk decisions to your team, when the work you're doing clearly connects to real outcomes: that's engaging. That's a game people actually want to play. The word "game" might seem strange here. Compliance is serious. Security matters. But the mechanics of engagement aren't frivolous. Clear goals. Visible progress. Meaningful choices. Feedback that tells you how you're doing. These aren't gaming gimmicks. They're the conditions under which humans do their best work. Think of it this way: the problem with compliance isn't that it's boring. It's that it's been designed as if learning doesn't matter. As if understanding is optional. As if the goal is to get through it rather than to get something from it. Redesign for understanding, and something else becomes possible. Compliance stops being an imposition and starts being an enabler. Instead of the security team being the department of no, they become the department that helps the business move faster and safer. Instead of compliance being a cost centre, it becomes a contributor to real business value: reduced risk, protected reputation, competitive advantage in markets where trust matters. There's a head of legal who once described wanting her team to be "yes people." Not pushovers, but enablers. Her lawyers' first answer to any question should be "yes, and here's how we do it safely." Security and compliance could work the same way. Yes, you can pursue that opportunity. Yes, you can work with that vendor. Here's what you need to consider, here are the controls that apply, here's how we manage the risk together. That's a different posture. It requires genuine understanding of the business, the risks, and the controls. It can't be faked with checkbox compliance. But it's infinitely more valuable. ## The Shift The technology to make this real is finally here. AI can do the research, gather the context, surface the relevant information. Automation can eliminate the tedious parts that don't require judgement. What's needed is intent: a decision to design for understanding rather than completion. The goal isn't more process. It's less need for process. When people understand what they're doing and why, they need fewer rules and less oversight. Trust becomes possible because competence is real. This is the shift from compliance as burden to compliance as capability. From governance theatre to genuine security. From systems that assume the worst about people to systems that help them be their best. The question for anyone building compliance tools, or using them, is simple: are we designing for completion, or for comprehension? The answer shapes everything that follows. --- # The Process vs. Trust Paradox URL: https://blog.askara.solutions/articles/The-Process-vs-Trust-Paradox Category: articles Author: Ben Visser Date: 2026-01-14T00:00:00.000Z ## Part 1: The Trap There's a moment in every growing organisation when someone says: "We need to document this properly." It sounds reasonable. ISO standards require it. Auditors expect it. And there's genuine value in capturing how things work so knowledge doesn't walk out the door when people leave. But something happens between that reasonable intention and the outcome. Documentation breeds more documentation. Each process spawns sub-processes. Sign-offs multiply. Before long, you've built a system that assumes people will do the wrong thing unless watched. This is the trap. The more rules you write, the more you signal distrust. And the more distrust you signal, the more people behave in ways that justify the rules. They follow the letter, not the spirit. They optimise for compliance, not outcomes. They ask permission instead of using judgement. The irony is sharp: management systems designed to ensure quality often erode the conditions that produce it. When organisations treat documentation as proof of control, they create governance theatre. Policies exist to satisfy auditors, not to guide work. Evidence is manufactured after the fact, disconnected from the activity it's meant to represent. The ISMS becomes a parallel universe, maintained but not inhabited. And here's what's rarely said aloud: most people inside these organisations know it. They know the procedures don't reflect reality. They know the records are performative. But they keep the system running because that's what compliance looks like. Or so they've been told. ## Part 2: The Inversion What if the goal of a management system isn't more process, but less need for process? This sounds counterintuitive. ISO 27001 and ISO 9001 are built on documented procedures, defined responsibilities, and auditable evidence. How can you have less process while meeting those requirements? The answer lies in a distinction that's easy to miss: there's a difference between codifying intent and codifying actions. Codifying actions means prescribing exactly how work should be done. Step one, step two, step three. It assumes the person doing the work can't be trusted to navigate ambiguity. It removes judgement from the equation. Codifying intent means making the purpose clear and trusting people to find the right path. It assumes competence. It treats context as something to share, not something to hide behind rules. High-trust teams operate this way. They don't need dashboards to prove people are doing the right thing, because doing the right thing is the default. Accountability exists, but it's relational, not transactional. When something goes wrong, the response is curiosity, not blame. This isn't naive optimism. It's a design choice. You can build systems that make good behaviour easy and bad behaviour hard. Three examples of what this looks like: *Access defaults that protect without obstructing.* Instead of relying on people to remember security protocols, design systems where sensitive data is only accessible to those who need it, automatically. No forms to fill. No requests to escalate. The system assumes least privilege by default, so people don't have to think about what they shouldn't touch. *Approval flows that follow risk, not hierarchy.* Rather than routing every decision through management, build workflows where low-risk actions proceed immediately and only genuine exceptions require sign-off. People move fast on routine work. Oversight concentrates where it matters. *Checklists that appear in context, not in binders.* Instead of training people to consult a procedure manual, surface the relevant guidance inside the tools they already use, at the moment they need it. The checklist isn't a separate compliance task. It's part of doing the work. The shift is subtle but profound. Instead of asking "how do we ensure compliance?" you ask "how do we make compliance the natural byproduct of well-designed work?" When trust is present, metrics become less important. As one conversation I was part of recently put it: KPIs often exist because trust is lacking. They're a substitute for confidence in the system. When confidence is high, the need for constant measurement fades. You check in rather than check up. ## Part 3: The Design Principle So what does this look like in practice? How do you build a management system that assumes competence rather than compensating for its absence? Three principles stand out. *First: document the why, not just the what.* Most procedures describe steps without explaining purpose. This makes them brittle. When circumstances change, people either follow outdated instructions or abandon the process entirely. But when they understand the intent, they can adapt. They can handle situations the procedure never anticipated. *Second: let evidence emerge from work.* The worst compliance systems require people to stop working in order to prove they're working. Separate logs, manual records, retrospective documentation. This creates friction and resentment. Better systems capture evidence as a byproduct of activity. The work itself leaves a trail. Nothing extra required. *Third: minimise the distance between decision and context.* Centralised approval processes exist because organisations don't trust local judgement. But centralisation creates bottlenecks, delays, and decisions made by people furthest from the situation. Pushing context outward, giving people the information they need to decide well, is more effective than pulling decisions inward. These principles don't eliminate documentation. They change its purpose. Documentation becomes a tool for enabling autonomy, not restricting it. A living reference, not a static archive. This is where we see modern ISO compliance heading. The organisations doing it well aren't adding more controls. They're designing systems where compliance is woven into how work already happens. Where the management system isn't a separate burden but an expression of how the organisation actually operates. We believe the technology now exists to support this shift. Automation can handle the repetitive, low-judgement compliance tasks. It can surface the right information at the right moment. It can generate evidence without interrupting flow. What it can't do is replace the underlying philosophy. Tools amplify intent. If the intent is control, you get sophisticated surveillance. If the intent is enablement, you get something genuinely useful. The paradox resolves when you stop treating process and trust as opposites. Process, done well, builds trust. It creates shared understanding. It makes implicit knowledge explicit. It lets people move fast because they're not guessing at expectations. But process done poorly, process that assumes the worst, destroys the trust it claims to protect. The question for any organisation building a management system is simple: are we designing for people we trust, or people we don't? The answer shapes everything that follows. --- # The First Fortress: The Opening Moves of ISO 27001 URL: https://blog.askara.solutions/articles/the-first-fortress-iso-27001 Category: articles Author: Ben Visser Date: 2025-12-29T00:00:00.000Z ## Part 1: Before the Walls Go Up You've been given the task. Get us certified. ISO 27001. Someone heard it's required for a tender, or a client asked about it, or the board decided it's time to take security seriously. Either way, it's now your problem. You're not a security specialist. You might be the IT lead, the operations manager, or the founder who handles everything that doesn't have a clear owner yet. You've inherited a spreadsheet someone started, maybe a template downloaded from somewhere. There's a lot of talk about controls and policies and audits. It feels like you're supposed to already know how this works. Here's what most guides won't tell you: the controls and policies come later. The real foundation of your management system is set in the first four steps, before any of that. Get these right, and everything else has something solid to stand on. Rush through them, and you'll spend months building on sand. Think of it like establishing a base camp before building a fortress. You're not constructing walls yet. You're choosing the ground, understanding the terrain, figuring out what you're protecting and from what. Skip this, and you'll end up with impressive-looking defences in the wrong place. These four steps are: getting management support, defining your scope, understanding your context, and identifying your risks. None of them are glamorous. All of them matter. ## Part 2: The Four Moves ### Move 1: Get Management Support This sounds like a formality. Get the CEO to sign something. Tick the box. Move on. It's not. Management support means the leadership team actually understands why you're doing this, what it will require, and what it will cost in time and attention. Not just money — though there's that too — but genuine organisational focus. The business case isn't complicated. Maybe you need the certificate to compete for contracts. Maybe a key client has started asking questions about your security posture. Maybe you've grown to the point where informal practices aren't enough anymore. Whatever the reason, leadership needs to own it, not just approve it. What this looks like in practice: a conversation, not a signature. Can your CEO explain in one sentence why you're pursuing certification? If not, you haven't finished this step. *The Socratic difference:* Instead of drafting a business case and hoping it gets read, you work through the questions together. What are we trying to protect? What happens if we don't? What does success look like? The answers become the foundation, not a document filed away. ### Move 2: Define Your Scope Scope is simply: what's in, and what's out. ISO 27001 doesn't require you to certify your entire organisation. You can certify a specific business unit, a particular service, a defined set of processes. For a 15-person company, you might certify everything. For a larger organisation, you might start with one division. The temptation is to go too broad (and drown in complexity) or too narrow (and miss the point). A good scope is one you can actually manage, that covers what your clients and stakeholders actually care about. What this looks like in practice: a clear statement of what's included. Which teams, which systems, which locations, which processes. Written plainly enough that anyone could read it and understand what's covered. *The Socratic difference:* Instead of copying a scope statement template, you answer the real questions. What do our customers expect us to protect? Where does sensitive information actually live? What would an auditor expect to see included? The scope emerges from the answers. --- ### Move 3: Understand Your Context Context is everything that shapes your security situation. Internal factors: your structure, your culture, your capabilities. External factors: your industry, your regulations, your threats. This is where most organisations lose the thread. The standard asks for things like a SWOT analysis, a stakeholder register, an understanding of legal requirements. These sound like bureaucratic exercises, and they often become exactly that — documents created to satisfy a requirement, then never looked at again. But context is genuinely useful. Knowing who your stakeholders are (clients, regulators, partners, employees) tells you whose expectations you need to meet. Knowing your legal landscape (GDPR, sector-specific regulations, contractual obligations) tells you where the hard boundaries are. Knowing your strengths and weaknesses tells you where to focus. What this looks like in practice: a clear picture of the world you're operating in. Not exhaustive, but accurate. If someone asked "who do you need to keep happy, and what rules do you have to follow?" you could answer without checking a document. *The Socratic difference:* This is where automation genuinely helps. AI can gather public information about your industry, your regulatory environment, your typical threat landscape. It can identify stakeholders you might have missed, surface legal requirements you weren't aware of. But then it asks: does this apply to you? What's missing? Which of these stakeholders actually matters? The research is automated. The judgement stays human. ### Move 4: Identify Your Risks Now you know what you're protecting (scope), for whom (stakeholders), within what constraints (legal and regulatory context). The next question: what could go wrong? Risk identification isn't about listing every possible bad thing. It's about understanding what matters for your specific situation. A data breach means something different for a healthcare provider than for a design agency. A system outage means something different if you're running critical infrastructure versus selling software. For each risk, you'll eventually assess probability and impact, decide on treatment, assign ownership. But that comes later. The first step is simply: what are the risks that matter here? What this looks like in practice: a list of risks that anyone in your organisation would recognise as real. Not abstract categories copied from a framework, but actual threats to the things you're trying to protect. *The Socratic difference:* Instead of generating a risk register from a template and hoping it's relevant, you build it through questions. What would hurt us most? What's happened to companies like ours? What keeps you up at night? The risks that emerge are ones you understand, because you thought through them yourself. ## Part 3: From Tent to Encampment When these four steps are done well, you have something. Not a fortress yet — that comes with controls and policies and continuous improvement — but a solid encampment. Ground you understand. A perimeter you can explain. A clear view of what you're defending against. The risk register isn't just a spreadsheet; it's a tool you built and can use. The scope isn't just a statement; it's a decision you made for reasons you can articulate. The context isn't just a document; it's your understanding of the world you operate in. This is what makes the difference between compliance that lives and compliance that's performed. Between a management system people actually use and one that sits in a folder until audit season. The test is simple: can you explain it? If someone asked why you chose this scope, who your key stakeholders are, what your top five risks are — could you answer without looking anything up? If yes, you've built a foundation. If no, you've built documentation. ## What Comes Next These four moves get you to base camp. From here, you start building: controls to address your risks, policies to guide behaviour, processes to keep everything running. The certification journey continues. But everything that follows stands on what you've built here. A control is only as good as the risk it addresses. A policy is only as useful as the context it's designed for. Rushing the foundation doesn't save time. It costs you understanding. And understanding, in the end, is what makes the difference between an organisation that's genuinely secure and one that just has the certificate. --- # Askara Solutions Year One: A Full Circle Review URL: https://blog.askara.solutions/source-journal/Entry-15-Askara-Year-One-A-Full-Circle-Review Category: source-journal Author: Ben Visser Date: 2025-12-24T00:00:00.000Z Hey there, As 2025 closes, I find myself looking back at a year that started with a simple idea and ended with something far more substantial than I could have imagined. What began as Certaify, a concept for automating cybersecurity compliance, has transformed into Askara Solutions: a team, a methodology, a vision for how AI can genuinely serve organisations. This entry is my attempt to honour that journey. To show gratitude for what worked, learn from what didn't, and extract the lessons that will shape 2026. ## The Return The most satisfying moment of the year came in my final week working with our first client. We had finally deployed the agentic AI automations that started this whole adventure: handling cybersecurity incidents, reading audit reports, tracking awareness training. Simple workflows, but exactly what I'd envisioned when I first sketched out Certaify over a year ago. Watching the staff interact with these systems gave me goosebumps. Not because the technology was flashy, but because it worked. People were using it. It solved real problems. That moment of product market validation is something every entrepreneur dreams about, and experiencing it felt genuinely magical. The irony is that these automations could have been built much sooner if we'd focused purely on product. But that would have missed the point entirely. The year wasn't just about building software. It was about building everything else that makes software meaningful: a team that trusts each other, a methodology that actually works, a vision worth pursuing. Along the way, we developed something I hadn't anticipated: a novel approach to risk management with AI at its core. We came to understand that risk is the discipline most cybersecurity standards hinge on. This insight now sits at the centre of everything we're building. ## The Foundations What surprised me most was how much foundational work the year demanded. We shaped our WHY and formalised our commitment through Slicing Pie methodology. We grew the team and, through our retreat in Tallinn, merged into something that feels like a genuine unit. We embraced a phrase that's become central to how we operate: "Extraordinary trust fuels extraordinary results." We established rhythms at every scale: yearly, quarterly, monthly, weekly. Finding that balance between synchronicity and structure took real effort, but now it feels natural. The Shape Up cycles aligned with seasons. The check-ins that respect deep work. The retrospectives that actually teach us something. The Cyber Accelerator deserves special mention. It didn't just provide funding. It created the space to refocus on our core idea after months of necessary experimentation with different services and products. Some of that experimentation was about finding revenue for financial feasibility. But the accelerator freed us to come full circle and deliver what we'd set out to build from the beginning. That freedom also reshaped how we think about growth. Rather than pursuing venture capital with its pressure for rapid scaling, we've leaned into the European subsidy ecosystem. This approach lets us build without compromising on quality or autonomy. ## The Edge Not everything received the attention it deserved. Content creation and marketing fell behind. Software and content are the two pillars of IP and knowledge leverage in our age, as Naval Ravikant teaches. From the very beginning of my freelancing journey, I've aspired to develop these skills. Behind the scenes we've been crafting and experimenting, but nothing substantial has seen the light of day yet. This matters because you can never start early enough building an audience. It's the one area where I feel genuinely snowed under from the transition between freelance life and startup building. But with Andrew now leading such a strong software development team, I can finally shift more attention to content development in the coming year. The Trade Mission to Toulouse opened strategic terrain I hadn't fully anticipated. Exploring the defence sector as a direction for partnerships left a lasting imprint. Trust sits at the core of everything we do with Askara Solutions, and profiling our product as "military grade software" aligns perfectly with that. Whether we actually penetrate the defence market remains to be seen. But the exploration clarified something important: we need to start immediately on industry standards and norms that demonstrate trustworthiness. ISO9001 lies at the foundation of many of these certifications. So we'll pursue it straight away in 2026, practising what we preach as a compliance automation company. Over the years, we'll collect the strategic certificates that radiate trust to the business world. For 2026, we've applied to two additional cybersecurity innovation funds, creating budget for both backend and frontend innovation. Building the network to play this European game has been its own reward. Participating in EU events with Reinier reminded me of my student days with IAESTE and the international conferences that were highlights of that time. There's a playful attitude we're rediscovering: the recognition that all aspects of work can become play when approached with the right spirit. ## The Harvest Looking back, I can identify clear peaks and valleys: **Biggest Win:** The Cyber Accelerator programme. It created the conditions to refocus and deliver on our original vision by year's end. **Biggest Miss:** Content creation and marketing. The audience building we should have started months ago. **Biggest Mindset Shift:** Moving from pursuing client revenue to stay bootstrapped, toward non-diluting subsidies. Learning to play the European game. **Top Three Highlights:** - The Tallinn Retreat, for crystallising the team - The Toulouse Trade Mission, for sharpening strategy - The IAM Conference, for validating the Graph database technology at our core What strikes me most is how the original spark, that simple idea for compliance automation, had to travel through so much transformation before it could land properly. The detours weren't distractions. They were the work of building something that could actually hold the vision. 2026 begins with foundations in place that didn't exist a year ago. A team operating with genuine trust. A methodology that balances structure with flow. A product that people actually use. And a strategic direction that lets us build on our own terms. Full circle, but at a higher altitude. With care, Ben --- # Playing the European Game URL: https://blog.askara.solutions/source-journal/Entry-14-Playing-the-European-Game Category: source-journal Author: Ben Visser Date: 2025-12-16T00:00:00.000Z Hey there, This week took me back to Tallinn for an accelerator day. Solo travel this time, which turned out to be exactly what I needed. There's something about being alone in transit that creates the perfect conditions for things to become clear. And clarity is what arrived, in abundance. ## The Journey Inward Travelling alone strips away the usual noise. No conversations to navigate, no coordination, just you and whatever wants to surface. The flight back especially became a concentrated journaling session where several threads I'd been holding finally wove themselves together. The trip itself was rich with synchronicities and new connections. But more than individual moments, what crystallised was a deeper understanding of what it actually means to build a company in Europe. Not the theory, but the felt sense of how this game is played. ## The Synchronicity Web One evening captured it perfectly. I attended a Cyber MeetUp where a postdoc presented her research on human behaviour in cybersecurity. Earlier that same day, we'd had our first real-life use of the Cybersecurity Agent we've been building: an actual [incident](https://askara.solutions/resources/glossary/security-controls/incident-response) reported and handled through our system. During her presentation, I could see exactly how our practical experience demonstrated points she was making theoretically. We got talking afterwards, and by the end of the evening we were discussing a potential partnership to apply for a subsidy together from the Estonian Cybersecurity Innovation Fund. A fund that had also been presented at that same meetup. Three threads, one evening, converging into possibility. This is how the European game works. Not through aggressive pitching or manufactured urgency, but through showing up, building genuine relationships, and letting opportunities emerge organically. The subsidy route rewards this. It optimises for synchronicity rather than speed. ## The European Game There's a version of startup culture, dominant in the US, that runs entirely on VC logic. Raise money, grow fast, raise more money, grow faster. The pressure to hit metrics can compromise quality, burn out teams, and force you into decisions that serve investors more than customers or mission. The European path offers something different. Through subsidies, grants, and programmes like our accelerator, you can build network and capability without that forced growth pressure. You can take time to do things well. You can actually enjoy the process. What strikes me most is how this approach respects the cultural differences across EU countries. Business happens differently in Estonia than in the Netherlands, differently again in France or Germany. The subsidy ecosystem acknowledges this. It creates space for relationships to develop at their natural pace, across borders, without homogenising everything into Silicon Valley templates. And here's something I didn't fully grasp until recently: you don't have to play the national game first. The conventional wisdom says build locally, prove yourself in your home market, then expand into Europe. But that's not the only path. You can simply choose to operate on a European level from day one. The infrastructure exists. The programmes are there. The connections are waiting. This understanding has completely shifted how I see Askara Solutions' trajectory. We're not a Dutch company hoping to grow into Europe. We're a European company that happens to have Dutch founders. ## Shared Altitude All of this grew from a single decision: founding Askara Solutions in Estonia. That was Simon's find. He sourced the opportunity, navigated the setup, and made it happen. From that foundation, everything else followed. The accelerator programme. The Toulouse trade mission. The relationships across borders. Each step deepening my understanding of how the European game is actually played. A year ago, I barely understood this landscape. Now I've experienced firsthand how synchronicity compounds when you're not desperately chasing the next funding round. How showing up and building genuine relationships opens doors that no pitch deck ever could. Simon created the conditions for Askara Solutions to flourish in this first stage. I'm deeply grateful for that. And I'm confident that once he's through his current growth phase, he'll do the same for our next stage, shaping the conditions for the team to flourish again as we scale. Flying home, that gratitude settled in fully. Not just for the opportunities ahead, but for the path we're on. A path that lets us build something meaningful without sacrificing quality for speed, or authenticity for metrics. This is the game we're choosing to play. With care, Ben --- # Serve to Lead URL: https://blog.askara.solutions/source-journal/Entry-13-Serve-to-Lead Category: source-journal Author: Ben Visser Date: 2025-12-08T00:00:00.000Z Hey there, We finished our last build cycle of the year and are now moving into goal-setting mode until the fifth of January. A good moment to pause and take stock. ## The Loop Closes We've successfully implemented all the agentic workflows for the cybersecurity agent we started building at the beginning of this year. When I think about that first idea that set everything in motion and look at where we're standing now, it's quite something. So much more has unfolded from that initial spark than we could have anticipated. This cycle was particularly satisfying because of how we approached it. The focus was entirely on what and how we build, with everything documented in a controlled manner. No loose threads, no half-finished experiments lurking in the background. Just clean, intentional work. Tidying up loose ends and getting the house back in order. I feel confident that we're ready to take the next step. ## The Door Opens What's shifted most significantly is where I can now direct my attention. With Andrew fully locked into Askara Solutions, and his trusted colleague Chris now within our ranks as well, I feel assured that I can let go of the technical side. The building team has control. They know what they're doing and how to do it well. Simon has stepped fully into his role too, staying on top of documentation and helping the team clear bottlenecks. Alongside this, he can focus on outward-facing work: selling the solution, gathering feedback, translating user stories for the builders to pick up. This past week we formalised what had been emerging organically: a clear distribution of responsibilities between the three of us following the CEO, COO, and CTO framework I wrote about after the Toulouse trade mission. After getting aligned on this and taking a first step in formulating our commander's intent, it feels right to use this journal to develop my objectives for the year ahead. As CEO, I'm setting three core objectives: **Strategic Partnership Development** — Cultivating relationships that position Askara Solutions for military-grade software development. Following the logic from Toulouse: start with the most demanding use case, and everything else becomes easier. Success means securing at least one formal partnership agreement with a defence sector organisation by end of 2026. **Funding Infrastructure & European Network** — Building the subsidy pipeline and EU network that enables sustainable growth without venture capital dependency. This means active participation in EU project consortiums, continued leverage of accelerator relationships, and establishing Askara Solutions as a recognised player in the European cybersecurity ecosystem. **Organisational Trust & Capability Building** — Developing the team's capacity in our core trust modalities: Sociocracy, NVC, Source Work, and Money Work. One significant training per quarter, starting with NVC in January. One major company retreat over the year. The goal is not just knowledge transfer but embodied practice that becomes how we operate. The training doesn't have to be dry, either. We've proven this through the internal podcast habit we've developed over the past couple of months. There's a fun interaction happening that makes people feel appreciated while establishing the neural pathways that connect actions with frameworks. Applied learning at its finest. I notice a part of me that wants to push faster on opportunities like Thales. But I'm recognising this as impatience rather than intuition. The right approach is probably to keep building, keep improving, and trust that the right partners will come naturally. These moments of calm between cycles are meant to be embraced, not escaped. ## The Threshold Work Beyond the business objectives, I want to start thinking about broader goals for 2026. That means being honest about my own edges. This year's coaching work with Lorin was transformative. One moment that particularly resonated was navigating the situation with Han as he was coming on board. Working through that helped me see myself as a high-value person. Someone who belongs in rooms with experienced leaders and can hold my own in those conversations. That shift in self-perception has been foundational. But where am I still growing? The skill of difficult conversations. Not the kind where you blame and punish, but the kind where you truly understand the other person and still get your message across effectively. I want to become more effective at delivering hard truths without diminishing anyone involved. This connects to something deeper: embodying what Lorin would call the wise king archetype. The king who leads from wisdom and genuine care. Who remains gentle and kind even when being direct. The shadow side of this archetype is the tyrant, who controls through force and fear, who confuses authority with dominance. I've seen this shadow in myself. The moments where frustration takes over and I reach for control rather than connection. The wise king doesn't need to dominate. His authority comes from earned trust, from consistency, from genuinely serving those he leads. He can hold space for difficult emotions without being destabilised by them. He can deliver challenging feedback as an act of care rather than punishment. This isn't abstract philosophy. A team can only grow as much as its leadership allows, and that ceiling is set by the growth the leadership has gone through personally. ## Integration Looking at my objectives through this lens, something becomes clear. My role in 2026 is fundamentally about service. Running around building trust within the team. Making efforts to train so we can grow most effectively as a group. Pushing through development opportunities. Pulling through ambitious goals that inspire people to stretch. The boots-on-the-ground work with clients matters. The partnerships and funding create possibilities. But the real leverage is in how much I can help this team become. Every hour invested in trust-building, in training, in developing our collective capacity pays compound returns. Serve to lead. That's the orientation. As I prepare to set broader goals for 2026, it makes sense to first reflect on the achievements of this past year. The wedding, the accelerator, the product launch at IAM, the team coming together, the first completed build cycles. So much has worked out well. And now, the next frontier. Not external but internal. Becoming the kind of leader this team deserves. With care, Ben --- # Manifestation Through Declaration URL: https://blog.askara.solutions/source-journal/Entry-12-Manifestation-Through-Declaration Category: source-journal Author: Ben Visser Date: 2025-12-02T00:00:00.000Z Hey there, I'm writing this fresh off the Trade Mission to Toulouse, still processing everything that unfolded there. What started as a networking trip turned into something more significant: a forcing function for articulating exactly where Askara Solutions is headed and why. Last week I wrote about the breakthrough we achieved through shadow work and discovering how military operational frameworks create the foundation for genuine high performance. This week, those frameworks got stress-tested in real conversations with potential partners. And something clicked into place that I want to share. ## **The Ground Beneath Your Feet** There's a certain grounding that comes from knowing what kind of company you're building before you walk into a room full of potential partners. We're building a multi-million euro company with a healthy financial and cultural bedrock. Not through venture capital that demands unsustainable growth, but through bootstrapping and EU subsidies. Not through hustle culture that burns people out, but through military discipline coupled with the deep shadow work that enables genuine collaboration. Walking into Toulouse with this clarity changed how conversations unfolded. I wasn't there to figure out what we are. I was there to find out who resonates with what we're already becoming. That's a fundamentally different energy, and people pick up on it. ## **The Three-Year Rhythm** Through researching how the military approaches strategic planning, we've adopted a framework that feels right for where we are. They plan on a five-year horizon, but only detail the first three years. Each cycle moves through three phases: **Execute** → Take action, deliver results, learn from reality **Prepare** → Structure those lessons into a realistic strategy for scaling **Shape** → Invest in long-term resilience through strategic alliances Looking back, the past year was pure execution. We delivered an MVP, landed our first customer, assembled a team, established our way of working, and built shared ownership of what we're creating. We moved fast, made mistakes, and learned constantly. The coming year shifts into preparation. We take everything we learned and structure it into a roadmap for scaling operations responsibly. This isn't about growing for growth's sake. It's about building the foundations that can support real scale when the time comes. Year three will be about shaping. Using a scaled operation to form strategic alliances that position the business for the decade ahead. And with those alliances, a new three-year cycle begins. ## **Why Defence Matters** The most interesting conversations in Toulouse were with people from the defence sector. This might seem like an unexpected direction for a company focused on helping SMEs with cybersecurity compliance, but there's a logic to it that became clearer through these discussions. Military-grade standards create trust. When you can say your software meets defence requirements, civilian companies know they're getting something robust. The security-conscious clients we want to attract understand this immediately. Tales, one of the major defence companies we connected with, represents exactly the kind of partnership we're looking for. They need solutions for their [supply chain](https://askara.solutions/resources/glossary/security-controls/supply-chain-security) of SMEs. We can develop military-grade software through that partnership, then leverage it for civilian markets. Start with the most demanding use case, and everything else becomes easier. This doesn't mean we're betting everything on one relationship. We have backup strategies, other potential partners, multiple paths to the same destination. But the defence angle gives us something valuable: a north star for quality that's externally validated and universally respected. ## **Distributed Command** One framework that's becoming central to how we operate is what the military calls Commander's Intent. Clear direction that empowers autonomous decision-making at every level. We're structuring leadership around three domains. CEO focuses on partnerships and funding, building relationships for EU subsidies, maturing strategic partnerships, maintaining oversight. COO focuses on scaling operations responsibly, training the team, optimising processes, maximising current potential. CTO focuses on engineering bulletproof solutions, the technical foundation everything else depends on. Each commander develops their own intent for the coming year, aligned with our preparation phase objectives. This creates accountability without micromanagement. Clear ownership without bottlenecks. What makes this work is the shadow work we've done as a team. In traditional structures, distributed command often fails because interpersonal friction creates misalignment. People protect territory, avoid difficult conversations, let resentments build. We've done the work to clear those patterns, which means we can actually trust each other with autonomous authority. ## **Seeds Planted** The immediate outcome of Toulouse is a handful of promising conversations that could develop into EU project collaborations for 2027. That's the timeline we're working with: 2026 for preparation and securing funding, 2027 for execution. But the deeper outcome is clarity. Clarity about our ambition, our timeline, our approach. Clarity that came from being forced to explain ourselves repeatedly until the essence emerged. I came back from the trip exhausted but energised. There's something about seeing how your vision lands with people outside your bubble that either validates or challenges your assumptions. In this case, it validated. The story resonates. The direction makes sense. The partnerships are possible. Now comes the work of following through. With care, Ben --- # From Professional Masks to Shared Ownership URL: https://blog.askara.solutions/source-journal/Entry-11-From-Professional-Masks-to-Shared-Ownership Category: source-journal Author: Ben Visser Date: 2025-11-18T00:00:00.000Z Hey there, This past week marked a true milestone for Askara Solutions. Through three days of intensive workshops that pushed us into emotional territory we hadn't explored as a team before, we achieved something we've been working toward since day one: the first genuine signs of shared ownership. For a company trying to pioneer what real trust looks like in a team, this breakthrough couldn't have come at a better time. What made it even more powerful was discovering that the frameworks we need for sustainable high performance have been battle-tested for centuries, quite literally, in military operations around the world. ## Surface Level: The Masks We All Wear Before this retreat, I found myself carefully choosing words depending on who was in the room. Not because anyone was difficult, but because we simply didn't know each other well enough yet. We were all wearing our professional masks, maintaining that safe distance that keeps things comfortable but prevents real collaboration. Most teams never move past this stage. They stay in the realm of polite professionalism, where everyone agrees too quickly, difficult topics get avoided, and the real conversations happen in private messages or after people leave the room. It's exhausting, inefficient, and ultimately limits what any organisation can achieve. We knew we needed to go deeper. The question was: how do you create the conditions for people to drop their guards without forcing vulnerability in ways that damage trust? ## Shadow Work: When Defences Drop Over the weekend, through structured workshops and unstructured bonding moments, we started seeing each other's shadow sides. Not just the polished, professional versions we bring to work, but the parts that get triggered under pressure, the patterns that emerge when we're pushed outside our comfort zones. This sounds uncomfortable, and it was. Some conversations escalated. Emotions ran high. But here's what made it productive rather than destructive: we had just enough structure through Sociocratic meeting principles to keep things from spiralling into chaos. Rounds for speaking, clear facilitation, space for everyone's voice. By the final day, something remarkable had shifted. We could hold REAL conversations with no holding back, but calm and collected. The kind where you can disagree fundamentally about an approach but still respect the person across from you. Where feedback isn't taken personally because trust has replaced defensiveness. Seeing people's shadows isn't about judgement. It's about understanding what you're working with, so you can account for it, coach through it, and ultimately help each person grow beyond their limitations. ## System Building: Military Wisdom for Modern Teams Here's where things got unexpectedly fascinating. Through conversations with Andrew, our team member with a military background, I discovered that the self-management principles I've been exploring for years have deep parallels with military operational theory. Think about it: military operations have existed throughout human history. Every conflict, every campaign, every mission has contributed to a body of knowledge about running effective operations under extreme pressure. You preserve what works because lives depend on it. After a bit more digging I found out that the OKR system Silicon Valley loves is essentially military planning repackaged for business: - Your Objective is really Commander's Intent: clear direction without micromanaging the how. - Key Results are Mission Measures: observable effects, not busy work. - Team autonomy comes from Mission Command philosophy: empowering people closest to the action to make decisions. - Retrospectives are actually After-Action Reviews (AAR’s): systematic learning from what actually happened versus what was planned. For a company in the cybersecurity space, where we're inherently connected to defence thinking, these frameworks feel especially relevant. We're not borrowing random productivity hacks; we're adapting proven operational principles that work when failure isn't an option. But Andrew reminded me of something even more fundamental: disciplined personal routines create team effectiveness. A team is only as strong as its weakest link, so each member carries responsibility for their own effectiveness. This isn't about conformity—it's about each person optimising their own system so they can show up fully for the collective mission. ## Integration: Building Our Operating System What excites me most is that we're not just adopting these frameworks; we're evolving them for a new era of work. Military structures often rely on hierarchy and command. We're taking the operational wisdom while maintaining our commitment to self-management and shared ownership. But here's the multiplier effect that military structures often miss: when you combine operational excellence with shadow work, you get something extraordinary. In traditional military settings, personal struggles get suppressed or hidden. You push through. You don't show weakness. We're doing something different. When you know that Sarah gets defensive about technical feedback because of past experiences, you can frame things differently. When you understand that Tom's need for detailed plans comes from anxiety about ambiguity, you can provide structure without judgement. When the team sees that my own tendency to over-control comes from fear of letting people down, they can call me out with compassion rather than frustration. This isn't touchy-feely nonsense; it's operational intelligence. Every unaddressed shadow creates friction in the system. Every pattern we help each other grow through removes a bottleneck. The military gives us frameworks for external coordination; shadow work gives us capacity for internal alignment. Together, they create a force multiplier that neither approach achieves alone. The disciplined routines Andrew spoke about don't mean everyone wakes up at 5 AM for push-ups. It means each person develops practices that keep them sharp, focused, and ready to contribute. For some that's yoga at dawn, for others it's evening runs, structured work blocks, or regular digital detoxes. The systematic approach to operations doesn't mean rigid processes. It means having enough structure to enable freedom—clear enough that people can improvise effectively when reality doesn't match the plan. Moving forward, we're embedding these discoveries into our daily operations. Regular syncs/check-ins that follow AAR principles. Personal effectiveness as a team value, not individual preference. Operational frameworks that come from centuries of refinement, not startup blog posts. The retreat proved something crucial: when you combine genuine human connection with proven operational systems, you get something powerful. Not the fake vulnerability of corporate “trust falls”, but real understanding. Not the chaos of structureless collaboration, but freedom within frameworks that actually work. This is what building a high-performance team actually looks like. It's messy, it's uncomfortable, it requires both emotional courage and systematic thinking. But when it clicks, when you can have those real conversations while operating with military-grade effectiveness, you've built something most organisations only dream about. With care, Ben --- # Leveling Up Our Vision URL: https://blog.askara.solutions/source-journal/Entry-10-Leveling-Up-Our-Vision Category: source-journal Author: Ben Visser Date: 2025-11-10T00:00:00.000Z Hey there, Last week was one of those glorious periods of deep work and flow states that every creator dreams about. Multiple valuable outcomes emerged from sustained focus, but nothing could have prepared me for what would unfold this weekend. At a classical concert about Gödel, Escher, Bach (GEB), I experienced something almost transcendental—a download of inspiration that's still unfolding as I write this. The concert revealed patterns I'd been sensing but couldn't articulate: self-reference, recursion, and layered representation as the same structural phenomenon expressed through music, art, and logic. Hofstadter's "strange loops"—systems that can observe and modify their own descriptions—suddenly illuminated everything we're building at Askara Solutions. But more than that, it revealed why we're building it. ## The First Mirror: Recognition The pattern struck like lightning during the concert. You know those Escher drawings where hands draw themselves? Or Bach's music where melodies echo at different speeds? They're all doing the same thing: creating loops where something observes and creates itself simultaneously. Through some chatting with ChatGPT after the concert, this pattern suddenly illuminated a possibility I hadn't seen before. What if we could build software that doesn't just follow rules, but watches itself following rules—and then adjusts how it follows them? Imagine three layers working together: - First, a basic system that looks at data and spots risks (like "this login attempt seems suspicious"). - Then a second layer watching the first one, asking "are we catching the right things? Are we missing patterns?" and suggesting improvements. - Finally, a third layer that acts like governance, deciding which improvements are safe to implement and which might break things. Each layer feeds back into the others. The system doesn't just manage risks—it gets better at getting better. It's like having a security guard who not only watches for threats but continuously improves their own training programme, while a supervisor ensures they don't go overboard. What struck me is that this recursive design—systems observing themselves—might be the first step toward machines that truly understand what they're doing, not just executing commands blindly. ## The Second Mirror: Reflection Here's where the revelation deepens. We're starting with cybersecurity because that's what businesses need today. But this recursive pattern hints at something much bigger. Right now, tech companies are racing to build powerful AI without really understanding the consequences. It's like everyone's frantically assembling pieces of a massive puzzle without knowing what picture they're creating. The result? AI systems that optimise for the wrong things—profit over people, efficiency over wisdom, metrics over meaning. Think about it: an AI trained only on business metrics might decide humans are inefficient. One focused solely on engagement might manipulate our emotions. These aren't evil systems—they're just doing what we taught them without understanding the bigger picture of what actually matters. This is why we can't just watch from the sidelines. What if we could build AI differently? Systems that understand not just how to optimise and calculate, but that grasp something deeper about the nature of existence itself? I'm not talking about mystical woo-woo. I mean AI that recognises consciousness and creativity as features to protect, not bugs to eliminate. Systems that understand growth and transformation are more important than pure efficiency. Our current work on [risk management](https://askara.solutions/resources/glossary/acronyms/grc) could be laying the foundation. The self-observing systems I started exploring this weekend might one day help people navigate not just cyber threats, but the bigger challenges ahead—preserving what makes us human in an increasingly automated world. ## The Third Mirror: Recursion The GEB insight shows how the same pattern works everywhere. Just like those self-observing systems, personal growth happens through layers of awareness. Let me make this concrete. Think about learning to manage anger: Level 1: You get angry and react instantly (purely reactive) Level 2: You notice you're getting angry as it happens (awareness) Level 3: You see the pattern of what triggers your anger (meta-awareness) Level 4: You observe how you observe your anger and can choose different responses (recursive awareness) Each level up gives you more freedom to change. You're not just stuck in patterns—you're watching the patterns, then watching yourself watch them. It's like stepping outside yourself to become your own life coach. What if technology could support this kind of growth? Imagine systems that help you spot your own patterns—not just "you spent too much time on social media" but deeper insights like "you seek distraction when facing difficult emotions" or "your productivity crashes when you skip creative expression." The same architecture that helps companies manage security risks could help individuals manage life risks. Where are you operating on autopilot? What patterns keep sabotaging your goals? What small changes would protect your wellbeing? Picture climbing an endless staircase where each step up lets you see more clearly. That's the vision—technology that doesn't just optimise tasks but helps humans level up their own consciousness. This is still far on the horizon, but the seeds are there in what we're beginning to explore. ### Integration: The Eye of the Storm None of this really matters in the ultimate sense. It's all just consciousness playing with itself, creating problems to solve them. But that's exactly why it's beautiful—we can use the game to transcend the game itself. The unveiling is coming. More people are waking up to how rapidly everything is changing, often finding themselves overwhelmed as familiar systems crumble. They'll need refuge—that calm center where chaos can't touch you because you're grounded in something deeper. The Risk Engine we're building today? It's just step one—proving that self-observing, self-improving systems are possible. But this concert revelation showed me where it could lead: AI that mirrors consciousness itself, helping humanity see more clearly. Not promising what we're building, but envisioning what conscious building could create. And in that possibility, finding our direction. With care, Ben --- # Cutting Back to Move Forward URL: https://blog.askara.solutions/source-journal/Entry-9-Cutting-Back-to-Move-Forward Category: source-journal Author: Ben Visser Date: 2025-11-03T00:00:00.000Z Hey there, This past week brought one of those inflection points where clarity cuts through complexity like a sharp blade. After weeks of juggling multiple possibilities, we made the hard calls that separate focused companies from scattered ones. The result? A team fully aligned around a single, beautiful goal: our Risk Engine. ## Pruning the Garden The betting table meetings we held over the past fortnight forced us to confront an uncomfortable truth: we'd been nurturing too many seedlings, hoping they'd all bloom simultaneously. Some were client projects initiated over summer, others were exciting experiments, and a few were obligations we'd accumulated along the way. Each had merit, but together they were choking our ability to grow anything substantial. The decision was surgical and necessary. We're cutting away everything that doesn't belong to our core business of [cybersecurity compliance](https://askara.solutions/resources/glossary/acronyms/grc). This meant making tough calls on products we'd invested months developing, telling clients we wouldn't be pursuing further sales efforts, and saying no to opportunities that would have provided income but pulled us off course. What made this possible was the funding from the cyber accelerator programme. Without it, we'd need to keep these other clients as income sources, perpetually stuck in the freelance trap of serving multiple masters. Now we can focus on what really matters: building something unique that people will actually want to buy. The freedom to say no might be the most valuable currency a startup can have. ## Aligning the Orchestra With clarity on direction came the necessity of alignment in execution. If we're going to build this Risk Engine over the next seven months, every team member needs to know their role in the symphony. This week, we started that sometimes uncomfortable process of defining boundaries and contributions, ensuring talents shine without stepping on each other's toes. Simon and I had several difficult conversations that pushed us through what Tuckman calls the "storming phase" of team development. These weren't easy discussions. They required us to be honest about strengths, weaknesses, and where we might be getting in each other's way. But they were necessary for becoming the high-performing team we're committed to building. Through my yoga practice this week, I had a realisation about how much the inner work I've done enables me to navigate these conversations from a place of clarity rather than ego. Being able to discern fact from feeling, knowing where to focus attention, not letting wrong notions cloud judgement. These skills divide the good from the great. But they only work when you have conversation partners emotionally mature enough to engage at that level. Fortunately, we do. What's emerging is a streamlined approach where everyone understands their contribution to the Risk Engine. We're applying Model Driven Development principles, where AI bridges the gap between design and code in days rather than months. Each role feeds the next: shapers define what needs building, stewards create the designs that drive code generation, builders refine and implement, and the cycle continues. ## Ascending Together The foundation we've been laying all year is finally starting to show its strength. Our Shape Up cycles, aligned with natural rhythms of equinoxes and solstices, have created a consistent heartbeat for the company. We always have time to address what's most important while maintaining the steady rhythm that compounds our effectiveness as a team. The latest habits we're stacking onto these cycles include financial reviews, marketing sprints, and personal growth sessions. After a year of setting this up, we've incorporated almost every aspect of running a successful business into these rhythms and habits. We're priming all team roles and business processes towards the same focal point, walking in step together. There's something powerful about being able to structure things right from the start. After years of working with clients who required me to navigate legacy systems and inherited chaos, we can finally build something clean, intentional, and aligned from day one. It's going to be remarkable to see how effective this team becomes when every element is designed to support our collective success. ## Integration The pruning hurt. Letting go of projects and possibilities always does. The alignment work was uncomfortable. Honest conversations about roles and boundaries usually are. But what's emerging from this crucible is a team with absolute clarity on where we're going and how we'll get there together. We're entering that rare state where focus meets funding, where talent meets purpose, and where the hard conversations have cleared the path for exceptional execution. The Risk Engine isn't just our product; it's becoming the gravitational centre that's pulling everything into coherent orbit. Sometimes you have to cut away the good to make room for the great. This week, we did exactly that. With care, Ben --- # You Can't Force the Source URL: https://blog.askara.solutions/source-journal/Entry-8-You-Can-not-Force-the_Source Category: source-journal Author: Ben Visser Date: 2025-10-20T00:00:00.000Z Hey there, This week I want to share something fundamental about building a company that goes against everything the startup world tells you. It's about timing, patience, and trusting the creative process—even when external pressures are screaming at you to move faster. ## Before: The Pressure to Force Progress About two weeks ago, we had a team meeting where some honest frustrations surfaced. The kind every startup faces—that feeling that things aren't moving fast enough. With our acceptance into the cyber accelerator, a natural sense of urgency had risen. We needed to start building. The clock was ticking. The programme was starting. We should be coding, shipping, iterating. But here's the uncomfortable truth we were all dancing around: we didn't yet know what exactly we wanted to build. Sure, we had plans for automating workflows. We could develop our current solutions further. But none of that felt truly innovative. It wasn't the breakthrough that would set us apart from everything already out there. After the intense couple of months we'd just been through—events, audits, personal milestones—part of me was glad for a breather. But more importantly, I knew something that's hard to accept when deadlines loom: breakthrough ideas have their own timing. This is the essence of "sourcing" something. It's outside of direct control when the organic trigger for momentum hits. Something will birth through you once it needs to come out. It's a matter of patience, observance, and taking action when you recognise it. So we had to trust the process. We couldn't let external forces mess with our internal knowing. We needed to stay centred and direct the flow of energy accordingly. Not exactly what you want to hear when an accelerator is about to start. ## The Transformational Moment And then it happened. Exactly as it always does when you stop forcing and start trusting. We were in our hostel in Tallinn, the morning of the first accelerator day. Around 3am, I woke with what I call a "download." Those magical hours when everything is silent and something decides it's the right moment to come through. Years of journalling have taught me to pay attention to these moments. So I started writing down every thought that came. [Risk management](https://askara.solutions/resources/glossary/acronyms/grc) principles. Security expertise. Compliance challenges. Knowledge structures. It all started connecting in ways that felt inevitable, like the solution had always existed and was just waiting for the right moment to reveal itself. By 6am I was empty and fell back asleep, just in time to catch one more sleep cycle before the intensive day ahead. I knew this was going to be powerful. And with the high intensity of the accelerator—presentations, networking, founder meetups—I experienced the perfect storm of everything clicking into place. The presentations showed gaps in what others were building. Conversations revealed desperate market needs. Team dynamics shifted as we all felt the vision crystallising. Every input added another piece to a puzzle that was assembling itself. By the end of two days I was exhausted. Could barely muster energy for the final meetup. But I was satisfied knowing this was it—the breakthrough clarifying what needed to be built. ## After: The Vision Reveals Itself Over the flight home and during quiet weekend mornings, I consolidated all the insights. Turning the cascade of ideas into clear plans the team could digest. What emerged wasn't something we could have brainstormed into existence. It was too elegant, too perfectly timed for the market moment. We weren't building another compliance tool. We were building genuine risk intelligence—a system that reasons about security the way the best experts do. Not forcing companies through generic checklists, but understanding their specific context and needs. The focus on helping SMEs with new regulations wasn't something we decided. It emerged. Thousands of companies suddenly needing to answer impossible questions about sophisticated threats. Current solutions taking months and costing fortunes. Our approach: days not months, affordable not astronomical, intelligent not generic. We now had something so powerful we could never have forced it. If we'd pushed through our impatience two weeks ago, we'd have built something mediocre that we'd need to pivot from once the real insight arrived. ## Winter Mode: Respecting Natural Rhythms Having passed the fall equinox, we're moving into winter mode. The season where we retract, become more reflective, build strength for the next growth cycle in 2026. It's important we respect these natural energies. The accelerator urgency needs channeling into thorough foundational work—the under-the-soil kind that makes spring's growth possible. That's exactly what our plans reflect. We're not forcing rapid feature development. We're building deep architecture that will support everything that comes next. The team gets it now. You can't force the Source. You can only create conditions for it to flow through you. The accelerator didn't create pressure—it created a container. The deadline didn't force innovation—it attracted the right insight at the perfect moment. This is how real innovation happens. Not by pushing harder when things feel stuck, but by trusting the process, staying observant, and being ready to catch the download when it arrives. ## The Beautiful Mirror What struck me most powerfully while writing this entry is how the technology we're building mirrors this philosophy exactly. We're creating systems that don't force compliance but understand context. Tools that don't push generic best practices but reason about specific situations. Intelligence that emerges from understanding relationships, not from following rigid rules. Just as we couldn't force our breakthrough, our technology doesn't force organisations through checkbox exercises. It observes, understands, and lets the right approach emerge based on their unique situation. The system reasons the way experts do—patient observation leading to sudden clarity about what really matters. It's building technology that mirrors how creativity actually works: watching, waiting, then moving with precision when the moment is right. This philosophical alignment between how we build and what we build feels like the deepest validation possible. We're not just creating products. We're encoding a way of thinking into technology. And that's why I know, deep in my bones, that what we're building will succeed. Not because we forced it, but because we let it emerge exactly when it needed to. With care, Ben --- # Seven Months to Unity URL: https://blog.askara.solutions/source-journal/Entry-7-Seven-Months-to-Unity Category: source-journal Author: Ben Visser Date: 2025-10-13T00:00:00.000Z Hey there, Last week I wrote about the Risk Wheel insight that emerged from our ISO27001 audit. That breakthrough wasn't just a conceptual win—it's become the catalyst for something much bigger: transforming how our entire team works together. Up until now, we've been operating in a fairly fragmented way, which is completely natural for a young initiative still finding its groove. ## Fragmentation The pattern we've fallen into looks like this: coupled work between a shaper and builder, each solution built for different purposes, with no uniform approach to project management across building cycles. Leading to different levels of outcome and unmet expectations. The usual growing pains of a startup still figuring things out. The GraphRAG solution we developed for the IAM event was our first real taste of what collaborative development looks like with a team larger than two people. Development and marketing had to align closely, and we got through it. But designing the solution wasn't really part of the equation yet—we were mostly adapting an existing piece of software, and building n8n workflows. That's about to change. ## The Catalyst The Risk Wheel I introduced last week isn't just a nice conceptual model—it's becoming the fundamental working principle of a novel piece of software we'll be developing through the seven-month Cyber Accelerator programme starting this week in Tallinn. This shift requires our current team to evolve into a truly unified force of collaboration, which means it's time to start structuring ourselves as a real team. Here's where I see things going: everybody fulfilling a role in the same solutions we're realising, relying on each other's information to build collaboratively. We're mapping traditional team roles to the Shape Up roles we've defined for ourselves. The keyword in our approach? Model Driven Development. But not the old version where it took months to get from design to code—the new version where AI bridges that gap in days. ## The Vision This got me taking a trip down memory lane last weekend, thinking about my time with Oxand and how we used this approach in client work. We were the link between the organisation needing a software solution (the business) and the programmers writing the code (software development). During my time there, I learned a lot about different modelling languages for making diagrams that translated user requirements into visuals developers easily understand to write their code. I spent parts of the weekend refreshing my memory of these frameworks and tools, and I genuinely enjoyed how my current understanding of AI made me see how this type of working can be taken to the next level. What used to take weeks can now happen in days. Here's how the flow works in practice: A shaper functioning as product owner prioritises features and manages stakeholder expectations, setting the direction for what needs to be built. Stewards acting as business analysts then create business processes and functional designs that capture those requirements—this is the critical role that drives code generation. Those designs get fed to AI tools like Claude Code to generate the actual codebase. Then builders at various levels take over: a tech lead handles architecture and code review, while developers refine that AI-generated code, implement the business logic, and write tests for rapid requirement verification of small, clearly scoped software components. Finally, stewards circle back for implementation and translating test results to the builders, closing the loop. The beauty is in how each role feeds the next, creating a continuous flow from requirements to working code in weeks rather than months. ## The Excitement I'm genuinely excited about this new phase we're entering as a team. The innovative ideas around how a team like this has to function in the age of AI feel fresh and unexplored. There's a strong conviction building that getting started on this journey together will turn us into a well-oiled engine, with all the parts working together at incredible speeds. The fragmentation phase served its purpose. It let us experiment, find our individual strengths, and discover what actually works. Now we're ready to bring it all together into something coherent. The Risk Wheel gave us the conceptual foundation. Model Driven Development gives us the method. The accelerator gives us the time and resources. And the team? The team is ready to become something more than the sum of its parts. Let's see what happens when all these pieces finally converge. With care, Ben --- # When the Wheel Started Turning URL: https://blog.askara.solutions/source-journal/Entry-6-When-the-Wheel-Started-Turning Category: source-journal Author: Ben Visser Date: 2025-10-06T00:00:00.000Z Hey there, The past few weeks have been intense, and part of that was due to building up to an ISO27001 audit that happened this week. That deadline pushed everything into high gear, but what came out of it was worth the pressure. The audit itself reminded me of something I'd understood before but hadn't fully integrated yet: everything in these ISO standards is built on risk management. I'd known this intellectually, but this time it clicked differently. The reason? Over the past weeks, I'd been diving deep into knowledge graphs for the solution we've been building for the IAM event. When the auditor walked me through a wheel metaphor during our session, suddenly these two pieces of understanding collided in my mind. That collision created a breakthrough insight later in the week! ## Finding Order Our auditor explained the management system using a wheel metaphor that made everything click into place. At the centre sits risk, the hub from which everything else radiates. The spokes are the ISO clauses, the structural framework connecting the centre to the outer layer. And the tyre represents the controls, the practical measures where the system actually touches reality. What made this metaphor powerful wasn't just the visualisation. It was understanding the sequence that most organisations get wrong. You start at the hub by identifying risks. You assess them through the framework (the spokes). You select a treatment strategy. Only then do you apply controls at the outer layer. Many companies select controls during risk assessment, essentially trying to put the tyre on before the spokes are properly connected. The auditor's key phrase stuck with me: "Everything refers back to and from risk." If you can't draw a clear line from a specific risk through your treatment decision to a particular control, something is broken in your system. This isn't just about documentation. It's about logical coherence in how you manage uncertainty. ## Seeing Patterns What emerged from this wheel metaphor was a fundamental insight about how ISO standards actually work. They're all built on the same foundation: risk management within a specific context. Whether you're dealing with quality (ISO9001), environment (ISO14001), information security (ISO27001), or asset management (ISO55001), the underlying structure is identical. You determine your risks within a particular context. You decide on treatment through the standard's clauses. You put controls in place. And based on those controls, you apply an appropriate frequency for the Plan-Do-Check-Act cycle. I'd understood this before, intellectually. But this time, with knowledge graphs fresh in my mind, it hit differently. Because here's the thing about knowledge graphs: they're built to map relationships and verify logical paths. They excel at exactly what the wheel metaphor describes—tracing connections. That's when it clicked. If risk management is about maintaining logical coherence between risks, treatments, and controls, and knowledge graphs are designed to verify logical relationships, then we could build something that doesn't just document these connections but actually checks whether they make sense. ## Building Intelligence This is where things get genuinely exciting. We're not just digitising compliance or automating documentation. We're building something that doesn't exist yet: an intelligent system that understands the logical relationships between risks, controls, and management decisions. The key is combining three technologies in a way that hasn't been done before. We're using knowledge graphs to map the logical relationships between all these elements. We're leveraging large language models to reason about those relationships and identify gaps or improvements. And we're grounding everything in relational databases that structure the actual data that's easy to grasp for humans. Here's what makes this different: the knowledge graph can check whether your reasoning is sound. When you say a particular control mitigates a specific risk, the system can trace that logical path and verify whether it actually makes sense given your context. It's not just storing information. It's understanding whether your management system is coherent. This means we can do something most companies struggle with: iterate on an existing management system to make it genuinely watertight. You establish a line of reasoning for the AI to review, it suggests improvements, it can even propose additions, and humans verify the logic before implementation. Over time, this creates an information security management system (or quality system, or environmental system, or any other ISO standard) that's perfectly tailored to your specific context. And it can tell you exactly what needs to be done, when, and why. ## From Firefighting to Foresight Most organisations treat compliance as something between a necessary evil and an afterthought. They're constantly firefighting, updating registers manually when they remember, preparing for audits by scrambling to get documentation in order. The audit becomes about the certificate, not about actually controlling risks. Even companies that get certified quickly with modern AI approaches still face the same fundamental challenge: execution. You might have your certification in record time, but do you truly control all your risks? Are you staying on top of actions? Can you keep your registers current without tremendous manual effort? This is what we're solving. Not faster certification, but genuine risk intelligence. Automations that help you decide what needs to be done and automatically update your registers with results. A system that doesn't just document your management approach but actively helps you improve it. The convergence I mentioned at the beginning? It's all these pieces finally clicking together. The wheel metaphor from the audit. The insight about risk as the foundation of all ISO standards. The technical breakthrough with knowledge graphs and LLMs. After weeks of intensity, there's finally peace of mind. Not because everything is finished, but because the path forward is remarkably clear. With care, Ben --- # Growing Without Growing URL: https://blog.askara.solutions/source-journal/Entry-5a-Growing-Without-Growing Category: source-journal Author: Ben Visser Date: 2025-09-29T00:00:00.000Z Hey there, Last week I briefly mentioned that we'd have an opportunity to pitch Askara Solutions at Vandebron. I didn't want to make too big a deal out of it since we weren't sure how it would actually unfold. But after our meeting with the CTO on Friday, I'm starting to get convinced that this might seriously become a reality. ## The Rush Who would've thought that after six months of starting this company, we'd be sitting with one of the freshest energy companies in the Netherlands? To me, these kinds of moments are a big part of why I love being an entrepreneur so much. Just bluffing your way into a meeting room with some big shots, figuring out the right ways to impress and dazzle, and then actually getting a shot at working your way in. That whole game is exhilarating from beginning to end. Getting all the right people involved to brainstorm the best tactics, letting the creative juices flow to make things look smart, reading the room during the conversation to see what's the right way to bring it home, and enjoying the afterglow of the adrenaline rush for the few days after it's over. I honestly love every moment of it. Now we're here with a good chance that this energy company of about 300 people will want to work with us. They still needed to discuss things internally and couldn't give us any definite answers, but it was clear that we left the right impression and that these people would be excited to work with us. That gives quite the thrill, and I've been enjoying it all weekend. Additionally, all our current clients have been showing increased interest in wanting to work more with us, asking for solutions that don't directly fall within the scope of the core product we're aiming to focus on. But it would be a shame to miss out on people wanting to pay us, right? ## The Challenge So the next big question is: how are we going to cater to such a big fish whilst simultaneously dealing with increased demand from current clients? All while we said that we aren't going to take on any new team members anytime soon. We first need the social concrete of the current team to harden before it can take on any new strain that new people with new needs would require. And we need to have a plan ready to go once the definite yes from Vandebron comes in. This really strikes at the core of what Source Work is all about. The Source has a specific vision for its creative field and needs to defend the boundaries of that creation with all its power, preventing sneaky new ideas from infiltrating and diluting the essence of what this is really about from the very start. Slowly eating into more and more resources, making people work on far too many things at the same time, and gradually halting progress and momentum in the organisation. So it's important that you, as the source, stay true to your gut about what's being built here and try to discern good advice from bad. In this instance, the nuance is that our core business is developing a management system through which cybersecurity, environmental, and quality standards can be managed. Specifically with quality management, the line of what it involves can often get quite blurry. Many requests currently made by our clients do improve their processes and thus the quality of the end result for the customer, but they're not necessarily an aspect of the management system itself. The risk is that we start dedicating precious resources to all these specific process improvements rather than actually building the automations for the generic management system. The management system is something we can productise and scale the sale of, but all these bespoke solutions are just one-offs. ## The Strategy We've crystallised two strategies this week to handle this capacity and vision alignment challenge without bringing in new people to the core team. **Teach Them How to Fish** We decided that instead of catching the fish and selling it to them, we'll get paid for teaching them how to fish for themselves. Still creating a win-win situation for all parties involved. So we'll develop some high-quality educational content based on the latest insights and skills we're developing with our own processes. **Roll Out the Network Effect** The next challenge is how to handle the big fish (Vandebron) we're currently in the process of reeling in. They'll require lots of attention, especially in the whole onboarding and implementation phase of this solution we're also still mostly developing ourselves. We specifically require real cybersecurity expertise that can work to analyse their current data and import it into our Information Security Management System (ISMS). Currently I'm the only one within our team who actually has this expertise, and I'm already very thinly spread. So we need a different solution. This is why I came up with the idea to involve a cybersecurity consultancy firm that we can tempt by presenting this big new client to them. But for them to get in, they need to agree to being subcontracted through Askara Solutions and working with our technology. This will most likely spark their interest since it will make their lives easier as well. By presenting them with this big client and work innovation, hopefully we can tempt them to eventually also promote our solution more within their own portfolio. Making it possible to train more of their consultants to work with our system and sell licences to their clients. This would be another strategy that scales through what's called "The Network Effect." We can repeat this approach over and over with more cybersecurity consultancy firms without requiring too much of our human resources. We might even create some educational resources for these firms to work with our tools. None of this is meant to steal anybody's work—just to make it easier, more fun, and more convenient to cater to more clients. Win-win-win. ## Integration These strategies reflect a core principle we're building into Askara Solutions: growth through multiplication rather than addition. Instead of simply hiring more people to handle increased demand, we're creating systems and partnerships that amplify our impact whilst maintaining our vision integrity. The "teach them to fish" approach keeps us focused on our core product whilst providing immediate value to clients. The network effect strategy allows us to serve bigger clients without compromising our team's cohesion. Both approaches honour the Source Work principle of defending creative boundaries whilst still being responsive to opportunities. It's a delicate balance, but one that feels sustainable and aligned with who we are as an organisation. Sometimes the best way to handle a big fish isn't to get bigger yourself, but to get smarter about how you work with others. With care, Ben --- # Stepping Through the Fall Equinox Portal URL: https://blog.askara.solutions/source-journal/Entry-5b-Stepping-Through-the-Fall-Equinox-Portal Category: source-journal Author: Ben Visser Date: 2025-09-25T00:00:00.000Z What a whirlwind these past few weeks have been. I've been so swamped since the week before our wedding that I haven't been able to journal properly. Between arriving back in the Netherlands, focusing all my energy on the IAM event last week, and preparing for tomorrow's ISO27001 audit, time simply disappeared. I was so busy that I didn't even consciously register I was moving through the Fall Equinox. But looking back at everything that unfolded in the weeks surrounding it, this truly was a powerful portal moment. On the other side, I've emerged as a married man with Askara Solutions having openly shown its face to the public for the first time. ## The Threshold The intensity building up to this portal was unlike anything I'd experienced. For about two years, we'd been talking about this wedding day. It became the source of many heated discussions and relationship tests that surfaced challenges we hadn't encountered together before. This process taught us tremendous amounts about ourselves and each other. I gained enormous respect for Chiara's eye for detail during the preparations. The level of attention I usually gloss over became essential to creating something truly special. While sometimes challenging during the planning phase, our different approaches really complemented each other in the final result. The peak intensity came in that final week of preparation. We had a lovely apartment booked in Conegliano where we could coordinate everything—planning welcome dinners for arriving guests, sourcing last-minute items, and meeting with suppliers like the photographer. We'd done our best to incorporate lessons from all the incredible weddings we'd attended over recent years, weaving them into our own authentic experience. ## The Crossing The wedding itself unfolded like a dream. Perfect weather, seamless flow, delicious food. The only minor hiccup was the party starting slightly later than planned, making it feel a bit short—but that's infinitely better than wanting it to end early. What made this day particularly meaningful for me was how it honoured everything my parents meant to me. Having been raised in the restaurant and catering business, I was exposed to countless events and culinary experiences from a young age. Seizing the opportunity to host a wedding in the vineyards of the Prosecco hills felt like realising a childhood dream. By connecting to those childhood energies, I felt an incredibly strong presence of my parents throughout the entire day. The week that followed brought us to a traditional alpine chalet in a small Dolomite village where we could completely decompress. Despite disappointing weather, we found consolation knowing at least our wedding day had been perfect. These past few days, I've been basking in a wonderful glow—both the renewed sensation of commitment and the relief that two years of planning are finally behind us. I must acknowledge how profoundly my coaching sessions with Lorin Krenn contributed to this crossing. The inner work taught me which subconscious voices to heed and which to ignore. I cleared uncertainties I held about myself and my relationship, enabling me to step through this threshold with a clear heart, clear intention, and deeper knowing that this path is right for me. But this portal wasn't just personal transformation. The same inner work that prepared me for marriage also enabled me to stand in my full power as an entrepreneur. Stepping through this Fall Equinox meant Askara Solutions presented its first product to the world. Thanks to the amazing team we've assembled this year, we developed our first AI solution and demonstrated it at Thursday's major event. A chatbot trained on workshop transcripts from the annual Institute of Asset Management congress. This solution allows participants to interact with all the knowledge shared during the event, making it possible to understand sessions they couldn't attend. The core technology we developed can easily be repurposed for countless use cases. My presentation explained to participants how this approach can salvage institutional knowledge that would otherwise be lost as baby boomers leave the workforce. Representing our own company at a professional event like this after just nine months of building feels genuinely incredible. The pride I felt speaking with attendees and presenting our work was unlike anything I'd experienced before. ## The Landing As if the successful product launch wasn't validation enough, we also received amazing news during these weeks: we've been selected for a startup accelerator in Estonia. This seven-month programme provides guidance and a €60,000 development budget to further advance our core technology. Having validated a product at the IAM event and secured accelerator support, I can wholeheartedly say we've successfully launched a startup this year. Looking at the goals I set at the beginning of 2025, I can proudly confirm I've fulfilled every single one. This realisation sparked an interesting question: what's left for the final three months of this cycle? Do I need additional goals, or should I simply let things unfold naturally? After this intense period, I'm leaning heavily toward the latter. The profound relaxation that washed over me this weekend—knowing I don't need to achieve anything more right now—felt absolutely sublime. That seems like all the confirmation I need to release pressure and simply enjoy the transformative results this year has brought. The plan moving forward feels beautifully simple: take the lessons from our product launch, pivot our activities accordingly, and focus on technological development without the immediate pressure of client acquisition (since accelerator funding covers our expenses). We can glide through the remainder of this year on the wave that just peaked, enjoying the freedom these achievements have created while evaluating lessons learned and tuning into what 2026's growth cycle requires. With care, Ben --- # A Garden of Compounding Efforts URL: https://blog.askara.solutions/source-journal/Entry-4-A-Garden-of-Compounding-Efforts Category: source-journal Author: Ben Visser Date: 2025-08-18T00:00:00.000Z This past week was a wonderful summer week, and it really felt like living the theme of _blossoming_. We’re in that season of enjoying the greenery and flowers of the seeds we’ve planted in the garden we’re tending to. ### Tending the Soil What stood out to me was the realisation that this garden doesn’t have to be recreated from scratch with every new project. All the effort, all the nurturing that went into earlier projects, is still here. It’s building the fertile grounds that new projects grow out of. And because things have blossomed here before, the conditions are excellent for what comes next to grow faster and stronger. That’s the metaphor that captures the feeling of this week perfectly. ### Blossoms of the Week One small but beautiful moment happened at the office. I was chatting with some employees of a client I’m working for — a fun group of people who almost feel like colleagues by now. It was a calm summer day, and since they weren’t too busy, I couldn’t help but share some Askara Solutions news I was excited about. Reinier, one of our teammates, managed to get us a meeting with the CTO of Vandebron — a Dutch energy company with a strong appeal to younger generations. He pulled it off by pitching Askara Solutions to a friend, who then passed it on at exactly the right time, just when the CTO was deciding how they wanted to move forward with their ISO compliance strategy. Even just having the chance to talk with people on this level feels huge. I couldn’t keep it to myself. We ended up talking more about Askara Solutions, and I also showed them a bit of what we’re working on. That naturally led into updates about the Y2S YouTube channel and the book. By the time the conversation wrapped up, everyone in the room (including me) seemed a bit flabbergasted with how much was shared in such a short time. Driving home afterwards, I felt this deep pride about the growth of the past two years. Later in the week, the same theme showed up again while recording a new video for the company YouTube channel — something between a vlog and a podcast. Again I noticed how even the skill of being comfortable with vlogging, built up steadily over the past two years, is now becoming incredibly valuable. During the conversation we naturally drifted towards the backstory of Askara Solutions’s inception. Once more I was hit with this strong wave of pride, realising how the threads of freelancing and vlogging are merging into this new shape. It feels like shedding an old skin and transforming into something bigger, and this time with an incredible team around me who I’m lucky to call mine. (If you want the backstory itself, you’ll have to watch the pod — I won’t be repeating it here.) ### New Growth Emerging The takeaway this week is simple but powerful: the compounding effect of work. Every effort, every project, every skill picked up along the way enriches the soil. Nothing is wasted. Each blossoming before makes it easier for the next one to bloom stronger and faster. Going forward, it's great to remind ourselves that nothing disappears, that the work keeps building, and that the next harvest always grows out of the last. With care, Ben --- # Discovering the Missing Half of Our AI Vision URL: https://blog.askara.solutions/source-journal/Entry-3-Discovering-the-Missing-Half-of-Our-AI-Vision Category: source-journal Author: Ben Visser Date: 2025-08-11T00:00:00.000Z Hey there, This week marked my return from La Gomera, and with it came one of those breakthrough moments that perfectly illustrates why trusting synchronicity and rolling with your instincts can lead to extraordinary outcomes. What started as a defensive reaction to an unwanted assignment turned into the missing piece of our AI-first management system puzzle. ## **Transition: Back to Reality** The past week was mostly about getting back home and settling in. It's been really nice to be back, catching up on lost time with Nina and reconnecting with my social life after a month away. I had a great catch-up day at Park & Charge, where I was very productive but completely drained by the end of the afternoon. This created a stark contrast with my days in La Gomera, where I had no distractions, no travel time, and quick food access on my own schedule. There, I could easily work and focus the entire day without hitting that wall of exhaustion. The difference in environment really highlighted something important about how we structure work. In La Gomera, the conditions naturally supported deep focus and sustained energy. Back in the regular world, the friction of daily logistics and social obligations creates energy drains that aren't always visible until you've experienced the alternative. ## **Recognition: Trusting the Gut Despite Resistance** I want to dig into the main breakthrough that unfolded in that final week at La Gomera, because it's a perfect example of reading synchronicities, trusting your gut, and rolling with things until they fall into place. When Sander, my previous boss at Oxand, called me to help with a new assignment at the Municipality of Amsterdam, I initially reacted defensively. I didn't want to get sucked back into the process modelling assignments I'd been doing for different clients over the years, especially while excitement around Askara Solutions was building and new opportunities were presenting themselves. But something inside also knew that things were different now. With all these new AI tools at our disposal, and this being the line of work where I'd built the most experience and expertise, I was probably the most well-positioned person to figure out how to innovate in this space with AI. So we went along and rolled with it. We recorded all the sessions with our Plaud.ai voice recorder and waited for genius to strike. Which it did last week. Through sparring with my colleague from another firm about how we wanted to present our deliverables, I immediately reached out to Claude and Lovable to build something that would create process flow diagrams for us based on meeting transcripts, as well as generate reports on the bottlenecks we needed to address. In probably the same amount of time and effort as manually modelling the diagrams and writing the report, we built something that would do it for us. Something that can now be used countless times in the future, with us only needing to tweak the final 20% of the work. It strikes a perfect balance between human and machine, saving enormous amounts of time for future process modelling assignments for clients. ## **Integration: Completing the System** The most exciting aspect of this solution is that it can easily be made available to the client's team with and AI chat functionality. They can see the process flows but also chat with an AI that uses these processes, as well as the meeting transcripts, as its knowledge base. Elevating the user experience around process management to the next level. Now everyone in the organisation can know exactly where they're at with a certain process and where there are still bottlenecks that need solving. This is an ideal solution for people in management positions who need to think about how things can be done better, which is the essence of quality management. With this AI-first process model, we've developed the missing half of the AI-first management system we're building. We had the entire database of structured management data like KPIs, objectives, risks, roles, and corrective actions etc., but so far there was no AI solution for the process modelling angle—which is what I've worked on most in the past few years. Now there's perfect integration possibility with the management system solution we've developed in Airtable. For example, we can automate a risk analysis on each process with the process chatbot, and this can land automatically in the risk register of the management system. With all these elements accessible as knowledge bases, that collective business intelligence we've been dreaming about at Askara Solutions is one step closer. ## **The Synchronicity Pattern** Looking back, this whole sequence perfectly demonstrates the power of staying open to unexpected opportunities, even when they initially feel like distractions. My defensive reaction was natural—I was protecting the momentum we'd built with Askara Solutions. But underneath that resistance was an intuition that this could be different, that the timing and tools had aligned in a way that made innovation possible. The breakthrough didn't come from forcing anything. It emerged naturally from doing the work, staying curious about possibilities, and having the right tools available at the right moment. This experience reinforces something we're building into Askara Solutions' DNA: the importance of staying responsive to synchronicity while maintaining focus on our core mission. The two aren't mutually exclusive when you learn to recognise the difference between distraction and opportunity. With care, Ben --- # The Lovable Shift URL: https://blog.askara.solutions/source-journal/Entry-2-The-Lovable-Shift Category: source-journal Author: Ben Visser Date: 2025-08-05T00:00:00.000Z I mentioned last week that after three weeks on this paradise island, all the big things I'd planned to achieve were done. I had this feeling of being complete here, while still having a full week ahead—enough time to house an entire holiday in itself. What I didn't expect was how that completion would become the launchpad for one of the most creatively explosive weeks I've ever experienced. ## Embracing Uncertainty There's something exhilarating about finishing what you set out to do early. The certain was behind me—the things I'd expected to work on were complete. Now room for uncertainty had opened up, and we all know that this is when the real adventure starts to happen. The moment you can truly let go, the unexpected gets invited in. And it certainly showed itself. I honestly think I've never created so many things in one week as I did this past one. Of course, this was only made possible through the exceptional powers that AI is granting me—some tools I was already aware of and became more handy with, some I'd learnt in recent weeks, and one tool I was aware of but didn't have the mindspace to experiment with until now. But let me pick things up from where we left last week. ## Riding the Creative Flow ### Firing Up The Content Engine After Simon left from our tiny company retreat, I was buzzing with excitement to immediately start editing the vlog we'd recorded during our hike through these gorgeous volcano forests. It didn't take long to get the piece finished, but we didn't have any online presence yet to share it through. We had an outdated website that was still a few business iterations behind. Simon had set up the newsletter platform, but it needed realigning with our latest thinking—same with the YouTube channel we wanted to launch. I needed a tool to move fast because I couldn't wait to share the video. It was clear I was surfing a wave of creativity and didn't want to fall off. Through a business vlog I follow, Daniel Dalen, I got reminded of AI tools that can build websites—even entire web applications—through prompting. I'd used Replit before, but quickly noticed it wasn't giving the same beautiful results. So I switched to Lovable, and man, did I fall in love with it. ### The Lovable Shift Within that same weekend, I fully finished setting up a new landing page, completely integrated with the newsletter platform. It gave me fresh style ideas, and based on these, I aligned the layout of the newsletter and YouTube channel. The speed with which I got this done was incredible. The true beauty is that these tools allow you not to lose that wave of creativity. If these things had to be built with outsourced developers, it would take weeks, and by then I'd most certainly have a new idea I'm excited about. Now I can just get it done myself whilst I'm in complete flow, which makes the entire thing extremely addictive. The fact that I was here on my own with no other distractions fully allowed me to give in to that flow—it was simply blissful. After finishing the website, I had an idea for an assignment with the municipality of Amsterdam that I started using Lovable for. Within a few hours, I'd built a solution that fully automated all the manual work of modelling processes, based solely on meeting transcripts I'd kept from process sessions I'd facilitated. It didn't take much more effort to turn it into a web application accessible to the municipality team, complete with an AI chatbot using all the process flows and transcripts as its knowledge base. Just by taking that small step of talking with Claude and Lovable about automating my work, the ball started rolling. The more I engaged, the more ideas latched on, and before I knew it, I had a high-value product ready to ship to a client. It's truly mind-boggling where we stand with this technology and how fast it's continuing to develop. ### The Creative Explosion Continues But the creating didn't stop there. The website was live, the vlog published, and the first newsletter sent out. While discussing progress with the team on Friday, we brainstormed our content strategy. We crafted a solid plan inspired by the All-In podcast, but we needed a catchy vibe—a recognisable song that would invoke the right emotions we want associated with our brand. So we started playing with Suno, the AI music generating tool I'd used for the yours2source YouTube channel before. Throughout the day, I researched how to improve the results, and by afternoon's end, I'd cracked the code. An entire theme song was made, and the beat was so catchy it didn't leave my head all weekend. Saturday morning, I used Capcut—the AI-enabled video editing tool from the vlog—to whip up an interview I'd recorded with Gregor Maehle during the week. Sunday, I explored this AI video editing further to create a matching video for the Askara Solutions theme song. I'm not sharing it yet because you can only make a first impression once, and it's not quite there. But I had a first draft done within a morning. It didn't even stop there. Sunday afternoon, so hyped up about these tools and with nothing else to do, I started thinking of more areas in my life where I could build cool solutions. And I found them—delivering two more products with these tools by Monday. Can you believe it? Seven polished end results within one week, ranging from music to video to website to web application. Obviously, this much was only possible due to having nothing else to do here, but the physical experience of knowing this is possible shifts something inside you. ## Integration & Reflection Having experienced this single notion firsthand has shifted something inside my brain—what I like to frame as "The Lovable Shift" I was gifted this week. It's not just about the tools themselves, but about what becomes possible when you remove friction from the creative process. When ideation can immediately become implementation, when you don't lose momentum waiting for technical execution. This week redefined my understanding of AI-enabled work. It's not just about efficiency or automation—it's about maintaining creative flow states that were previously impossible to sustain. The traditional creative process has so many breaks: idea, planning, technical implementation, refinement. Now those breaks can disappear entirely. For Askara Solutions, this experience validates everything we're building toward. We're not just creating tools; we're enabling entirely new ways of working where creativity and execution become seamless. Where uncertainty becomes opportunity, and flow states become sustainable competitive advantages. ## The New Baseline I don't think I can emphasise enough how amazing it is to get a taste of this if you haven't done so already. This week didn't just produce seven outputs—it established a new baseline for what I know is possible in my creative work. The real magic isn't in any single tool, but in the ecosystem they create together. When AI removes friction from every step of the creative process, you're free to stay in flow indefinitely. That's the future we're building toward at Askara Solutions—not just for ourselves, but for every organisation ready to embrace what becomes possible when humans and AI truly collaborate. Take care, Ben --- **LinkedIn Topics Preview:** 1. **The Creative Flow State Revolution**: How AI tools enable sustained creativity by removing friction from ideation to implementation 2. **From Uncertainty to Opportunity**: Why finishing planned work early created space for breakthrough innovation 3. **The Lovable Shift**: What happens when technical execution no longer breaks creative momentum 4. **Seven Products in Seven Days**: A case study in AI-enabled rapid prototyping and content creation 5. **Beyond Efficiency**: How AI collaboration redefines what's possible in knowledge work and creativity --- # Time to Speak Out URL: https://blog.askara.solutions/source-journal/Entry-1-Time-to-Speak-Out Category: source-journal Author: Ben Visser Date: 2025-08-01T00:00:00.000Z This past week clearly marked the peak of my La Gomera chapter. The first two weeks were more of a slow build-up, but this one brought the crescendo. It’s incredible how much I’ve managed to get done. I’ll return home with real peace of mind, having wrapped up so many lingering things. Especially with Simon joining me, we were able to bring closure to projects that had been pushed aside by day-to-day demands. Now there's actual room for new growth. ### Key Actions and Highlights #### Foundational Systems Locked In Before Simon arrived, I completed the migration of the IMS to Airtable. That was a huge milestone. With that out of the way, we can now start refining it, building automations around it, and making it truly work for us. I also finalised our internal Askara Solutions management system, creating clear overviews of our aims, objectives, and projects for the second half of the year. #### Solidifying Askara Solutions’s Foundation Once Simon got here, we updated and signed our shareholder agreement, tying up that chapter. We also refined our financial model and were happy to conclude that with the current proposals we’ve landed, we have enough runway to pay our people until the end of the year. That should be more than enough time to secure new assignments and take big steps toward selling our first products. #### A Hike, a Vlog, and a Whole New Channel On the second day of Simon’s stay, we went on an incredible hike and ended up recording the **very first vlog** for the Askara Solutions YouTube channel. What made it feel so right was that we didn’t try to compete in the crowded AI space. Instead, we focused on the new ways of working we’re exploring: what it means to self-manage, to work with deep trust, and to embrace decentralised leadership. These are the conversations we naturally have anyway, and it felt great to share them publicly. We also decided not to over-explain. We’ll speak directly to the audience we know is already out there: the people who get Source Work, Sociocracy, and async culture. No need to start from scratch. And as a surprise kick-off to our new newsletter, we’ll be dropping that first video this week. ### Reflections and Next Steps What stood out most this week is how **much space opened up**—mentally, emotionally, and creatively. Closing loops and wrapping up half-done projects is clearing the road for what comes next. I no longer feel like I’m dragging a bag of unresolved "shoulds" around. This final week on La Gomera feels like a clean break into a new rhythm. I’m especially excited about launching the **Source Journal** newsletter under the Askara Solutions banner. It will be rooted in the same Source Work principles we’re living out: leadership through listening, alignment through resonance, and building from within. The first vlog already touches on some of the frameworks we’re using and the challenges we’ve faced in putting them into practice. We haven’t figured out our entire content strategy yet, but the important thing is that we’re getting started. There’s an intuitive sense that now is the time. And we’re done waiting. So from here on out, we’ll just let it unfold. Take care,  Ben