Skilled trade
Real things have to work. Errors become visible in practice, not in theory.
DEPTH · PERSONAL DEVELOPMENT
No straight career path. One continuing question.
More than 35 years of lived experience explain the way I ask questions. They do not describe a 35-year plan for ATLAS. ATLAS itself was not the goal. It emerged much later from concrete programming problems and from following each next logical question further than originally intended.
A FREE MIND AS A WAY OF WORKING
Not against rules. But not for rules merely because they already exist.
My professional path did not stay inside one discipline. It began in skilled trade, moved through master-craftsman responsibility, department and company leadership, project management and complex construction, then into BIM, document and data management, and finally into my own software and automation.
Those changes were not a break. They sharpened the same way of looking at work: first understand what actually happens, then ask what is truly necessary. If a boundary exists only because it has always been there, it can be questioned.
Leadership & projects
People, schedules, disciplines and decisions only work when relationships are understood.
Data & automation
As work became more digital, repetition, handoffs and lost context became increasingly obvious.
FOUR YEARS AS A LONG-DISTANCE MUSHER
16 huskies, one human – and only the team gets through.
A formative part of this life experience was four years with the Valkoira Alaskan Husky Kennel. With 16 sled dogs, long-distance journeys covered 300 or 600 kilometres through ice, snow and the wilderness of Scandinavia and Alaska.
Out there, cooperation does not come from an organisation chart. Every dog has a personality, strengths, limits and a role in the pack. As a musher you can carry direction and responsibility, but you cannot force every metre. You observe, respond to weather, terrain and team, trust experience and make decisions even when the path ahead is not already laid out.
Valkoira is therefore not a brand name invented later. The name comes from that real team – and the experience belongs to the long development from which the questions behind ATLAS later grew.
THE DIGITAL PRESSURE GROWS
Over roughly the last eight years, the question increasingly became a technical necessity.
As more digital tools appeared, the number of breaks paradoxically grew as well: data lived in different systems, documents lost their relationships, people carried context by hand, and each piece of software represented only part of reality.
A long-standing way of thinking therefore became a concrete technical task: how can a machine do more than store information? How can it retain enough context, relationships and consequences that people no longer have to bridge every gap between systems themselves?
NO ATLAS PLAN
ATLAS was not the goal. Each step solved the problem that had just become visible.
It began while programming. I was bothered by writing the same functions again and again. So I built universal modules and let the database decide who or what used which function.
Then ordinary exception codes became the next problem: they said that something had failed, but not enough about the situation. A wrapper emerged around four questions: who, how, where and why? From that, Question was born. All of this still lived in code.
There was no ATLAS roadmap behind it. There was only the habit of removing repetition, making context explicit and following the next problem far enough to understand it.
A SCIENTIFIC AND TECHNICAL CONSTRUCTION PROJECT AS ACCELERATOR
In 2019 the question did not change. The urgency did – and so did the practical ability to answer it.
In a complex scientific and technical construction project, science, construction, technical equipment, 3D models, documents, data and many disciplines met in one working reality. Existing tools could represent individual parts. The work itself required the relationships between them.
Over almost two years, practical necessity led to a largely automated 3D model. Large document collections, OCR, databases, converters and interfaces followed. Each technical solution made it clearer that no individual tool answered the underlying question.
These figures describe documented professional project experience. They are not ATLAS ROI, speed or customer-outcome claims.
DECEMBER 2025 · THE SPECIFICATION TURN
How do we get the misunderstandings between human and machine out of the way?
I asked an LLM that question. Its answer was: rules, specifications and a shared language. Rules were familiar. Specifications were not. My reaction was simple: then we do it that way. I did not know what that decision would lead to.
Code increasingly gave way to specifications. Then came the next question: what can you do with specifications? The answer was: almost everything. So the work continued step by step into the unknown, always with the next logical question rather than a finished target architecture.
Only in retrospect can the sequence be seen: how do we extract more and more of the logic from code? What must exist so a machine can find, relate and apply it? Registries appeared. Then matrices and graphs. Patterns became explicit. Ontology and telemetry followed. Each layer answered a problem exposed by the layer before it.
Performance was not the objective. The recurring question was: how much of this can a machine do on its own while still knowing what it is doing, why it is doing it and where it must stop?
THE COMPLEXITY CHANGES SIDES
Thousands of specifications were no longer my subject. That was exactly what the machine was for.
With every new specification, a layer grew that I could neither keep completely in my head nor wire reliably by hand. Field wiring, dependencies, versions and the question of which specification interacts with which other specification became a problem of their own.
The consequence was not to simplify that complexity again so I could manage it manually. The consequence was: the machine takes care of managing the specifications and their flow. My role remained vision, direction, questions and the view of the whole.
The specifications themselves increasingly were not written by me as a single author either. LLM roles worked as Author, Reviewer and Reviewer2: formulate, inspect, challenge and refine. I did not prescribe every individual connection. I worked with a system that could keep more and more of its own described reality machine-readable.
As that reality matured, the frame shifted as well. New steps were no longer proposed only from a human idea; they also had to fit what ATLAS had already described, constrained and required about itself. Architectural developments such as AMEX/ATEX were therefore not set by me as a prior target architecture, but derived from the existing ATLAS frame as a necessary next solution and then subjected to review again.
This does not mean that ATLAS decides outside human responsibility. It describes the point at which the machine-readable reality became strong enough to constrain the solution space itself: what conflicts with existing rules? What is missing? Which next structure is required? Where must the process stop and create a question?
WHAT ATLAS MEANS TODAY
What exists today is the result of an open-ended path.
Today ATLAS connects patterns, context, specifications, authority, execution and evidence. None of those layers was the original destination. They accumulated because each solved a newly visible problem in letting machines act with more context and less repeated human translation.
For customers, this depth is optional. The practical point remains simple: software should adapt to real work – not the other way around.
What does any of this mean for your situation?
You do not need to understand ATLAS before working with Valkoira. The starting point is always your real situation.