Applied AI · Design intelligence · Oslo
I design how AI thinks—
then show it in the interface.
I use four systems. Smia chooses the design method. VEV coordinates specialist agents. LOOM tests improvements against real outcomes. Kontor turns a build request into inspected work and stops at my gate.
D.01 / SMIA
ReceivesA design problem
→System moveSelect one fitting method
→ReturnsA checkable design output
Four systems · four different failures
Why these systems exist.
AI can produce quickly and still choose the wrong method, lose responsibility between agents, or learn the wrong lesson from an outcome, or blur who builds, checks and ships. I designed one system around each failure.
Smia chooses the method → VEV conducts the mission → LOOM tests the lesson → Kontor builds through a supervised workshop. I retain intent, judgment and acceptance.D.01
Smia
Chooses how to solve the design problem.Built because research, usability and visual craft should not collapse into one request to “make it look better.”
Understand Smia O.00VEV
Coordinates who does what—and where decisions stop.Built because multiple agents need explicit dependencies, inspectable handoffs and a human authority.
Understand VEV S.01LOOM
Turns real outcomes into tested improvements.Built because memory without evaluation repeats mistakes, while automatic self-improvement removes governance.
Understand LOOM E.01Kontor
Builds through a supervised workshop and waits for my decision.Built because the maker, reviewer and shipping authority need different roles, visible records and a founder-only gate.
Understand Kontor01 / Design intelligence
Chooses the right design method for the problem.
Smia is not a style machine.
Most AI design requests compress discovery, product decisions, usability and craft into one style prompt. Smia was designed to stop that collapse. It reads the maturity, evidence, surface, goal and access to users—then chooses one right methodology route.
SMIA → KONTOR
Smia selects the design route and its checkable output. Kontor can then build against that bounded method.
Follow the build handoff05 / Craft
Give the work a point of view.
A coherent direction is built around one memorable thing, with risks named honestly and AI-slop screened out.
Output · SAFE/RISK direction, quality-audited interface- 01SAFE/RISK
- 02Variant Divergence
- 03Quality Audit
02 / One CV · four design languages
One original plus three independently designed expressions.
Explore my CV in four different ways, designed through Smia.
The career story stays constant. The hierarchy, typography, colour, motion and evidence flow are designed anew—so each expression tests a different way of making the same work legible.
Open the recommended Norway CVConstant
One CV · the same experience, evidence and career story
Designed anew
Hierarchy · typography · colour · motion · interaction
Plans people can check.
A pastel project-controls field with tactile chapters, direct writing and inspectable proof.
Open CV 01
Six instruments. One operating picture.
A spruce-and-mint system where every chapter gets its own grammar while one grid holds it together.
Open CV 02
Make the work checkable.
A mineral-paper editorial CV tuned for fast Norwegian recruiter scanning and explained evidence.
Open CV 03
Project noise, made decidable.
A deep-spruce decision instrument that converges noisy inputs into one visible line.
Open CV 0403 / Multi-agent orchestration
From parallel models to one governed mission.
Several agents need more than a shared chat.
VEV is a graph-engineered mission runner. It turns an objective into typed work, assigns each node to the right specialist, preserves dependencies and makes the human decision boundary visible.
VEV → KONTOR
When a mission reaches a making node, VEV can route the bounded build to Kontor and keep its review record in the mission.
See the workshopVEV / GRAPH-ENGINEERED MISSION RUNNER
Coordinates specialist AI agents and keeps decisions with me.
VEV conducts the work.
I designed VEV because parallel intelligence without a work graph duplicates effort, loses context and blurs authority. Claude orchestrates, Gemini researches, Codex engineers, and consequential decisions stop with me.
Human intent entersBuild something useful without losing authority.
04 / Governed learning
Learning from work without handing authority to the system.
A learning loop needs evidence, a test and a gate.
LOOM is not memory, automatic self-improvement or a model rewriting itself. It is a governed learning system that converts real outcomes into bounded candidate changes and tests them before promotion.
KONTOR → LOOM
Kontor produces outcomes and review evidence. LOOM tests any lesson from that work before the workshop changes.
See where the work is madeLOOM / GOVERNED LEARNING SYSTEM
Turns real project outcomes into tested, reversible improvements.
LOOM learns without taking authority.
I designed LOOM because accumulated context is not the same as learning. LOOM records provenance and correction, writes the lesson, proposes a reversible change, compares it with a baseline and waits for human acceptance.
OUTCOME://CAPTUREDEvidence becomes a change only after every gate.
REAL WORKVERSIONED IMPROVEMENT
ACTIVE GATE / 01
Real outcome
Start with what happened in actual work—not synthetic activity.
- Guardrail
- No invented success
05 / Kontor · house of companies
The designed institution around one working, governed build engine.
A house of companies built around one founder gate.
Kontor is both a working build system and a larger institution design. The engine runs one supervised make-review-gate loop today. Around it, I designed a holding group with shared services and 16 complete operating companies across six sectors.
KONTOR / BUILD WORKSHOP
Designed institution · working engine
One group contracts the right companies. Open-weight crews build. Frontier seats think and check. I decide what ships.
A Program Director owns each programme and contracts only the companies it needs. Companies return inspectable artifacts as data; no company commands another. The current engine proves this loop before divisions graduate into the full group.
one group · six sectors · sixteen companiesDESIGNED GROUP / WORKING ENGINESHARED SERVICESProgram DirectorDelivery / PMOAppend-only recordGovernance / Trust
ACTIVE SECTOR / 01Front Office
Turns the outside request into a clear relationship, mandate and brief.
COMPLETE COMPANIES
Client Company · Communications Company
CEOCFOCPOCTOCOOCHROCISOChief of Staff
↓ Direction through CEOs↔ Contracts through the Program Director⋯ Group policy✕ No company commands another
Designed institution16 companies / 6 sectors
Working engine todayOne governed pipeline
Graduation ruleVolume earns company status
WORKING ENGINEOne programme moves through five accountable rooms.
Review failure returns to Make. Nothing ships without my keystroke.- Receives
- Your plain-language request
- Does
- Writes a bounded brief without inventing an interface.
- Writes to the record
- Original ask + job status
The ledger proves record integrity. It does not prove that a deliverable is correct; independent review does that work.
06 / Product built through the systems
Weaveplane v6 applies the practice to project setup.
One governed setup before delivery begins.
Weaveplane v6 is a product shaped by the four systems. It gives a project team one saved setup, visible readiness gates and separate decisions for review, approval and publication.
WEAVEPLANE / PRODUCT V6
Approved product and workflow foundation · 09 August 2026
A project should have one governed setup before delivery begins.
Weaveplane prepares, governs, approves and publishes a Project Setup across the tools an organisation already uses. It exposes missing authority and blocks publication until the required people, capacity, budget, decisions and destinations are resolved.
ACTUAL V6 PROTOTYPE
VIEW / 01Clickable behavior verified
One evidence record, two ways to work.
Guided AI and manual parameters edit the same twelve evidence groups. AI proposals stay proposals until the preparer accepts them.
Prototype evidence, not production software.07 / Engineering foundations
The practices underneath the named systems.
Context + relationships
I engineer what agents know—and what must remain connected.
Reliable AI work depends on the information selected for each task and the relationships preserved across a mission. These are engineering practices, not product names.
PRACTICE 01C
What the agent receives
Context engineering
I structure the smallest sufficient context for a role: durable mission briefs, source provenance, typed handoffs, write-back rules and context budgets that keep the signal without flooding the model.
- Role-specific context and acceptance criteria
- Persistent knowledge with source-aware write-back
- Selection, compression and contradiction checks
PRACTICE 02G
What the system must preserve
Graph engineering
I model dependencies, authority, provenance and knowledge as traversable relationships. A work graph routes execution; a knowledge graph supports path queries, impact analysis and evidence-backed explanations.
- Typed work nodes, edges and on-fail routes
- Knowledge, code and design relationship queries
- Dependency-aware routing and impact analysis
08 / AI organization
An AI organization, not a bag of prompts.
An AI organization is a governed division of labour. Each agent has a zone, typed inputs and outputs, review boundaries and an escalation path. The organization can act quickly without pretending model confidence is decision authority.
AUTHORITY LAYERSARAS / FOUNDER
Intent · constraints · judgment · acceptance
Researcher Gemini
Evidence, options, feasibility and prototype spikes.
Orchestrator Claude
Work graph, routing, integration and arbitration.
Engineer Codex
Implementation, testing, review and shipping.
ENGINEERING SUBSTRATEContext engineering + graph engineering
Delivery capacities
Sites
GitHub + Linear
Notion
Data Analytics
Docs · Slides · Sheets
09 / Professional evidence
The work that shaped the systems.
Smia, VEV, LOOM and Kontor did not begin as AI vocabulary. They grew from project-controls and product work where the method, handoffs, learning and shipping decision all had to stay visible.
First came the operating problems. The named systems came later.Project Planner · Interim Project Controls Manager
One Nordic portfolio needed a more reliable operating picture.
- Why
- A pipeline of 30+ projects needed forecasts, resource priorities and system ownership that leadership and delivery teams could both trust.
- What I did
- Owned analytical planning, scenario modelling and portfolio analysis; led the Skive modification plan; and carried the Omega PIMS-to-Omega365 migration through requirements, setup, training and governance.
+30%Forecast accuracy
£10MSkive modification
50+Omega365 users trained
Project Controls Specialist · Digital Systems Coordinator
Two assets needed one lifecycle view without hiding their differences.
- Why
- Brownfield and greenfield work carried different constraints across engineering, construction and production ramp-up.
- What I did
- Ran lifecycle controls, introduced critical-path and scenario analysis, and connected ERP, EAM and CRM with plant data for project and executive decisions.
2 × 150,000tonnes per year · biogas assets
Earlier operating foundation · IndiaKept brief here; available in the full CV.
Rationale Energy · Founder & PMO / Business Operations Lead
Built repeatable controls from bid to handover across 20+ energy and infrastructure EPC projects: portfolio reporting, procurement, risk and owner-side delivery.
+128% average annual revenue growth−25% procurement lead time−30% portfolio risk exposure
Power Electronics · Tendering & Technical Coordination
Produced 50+ compliant technical-commercial proposals and coordinated awarded work through procurement, installation, commissioning and handover while studying full-time.
The next useful edge
Bring me a difficult brief.
I'll design the system around it.
Product design, agent orchestration, knowledge systems and the space where all three have to work together.
Start a conversation