A live roadmap for learning, building, and proving practical AI architecture capabilities.

AI capability learning map

This cookbook is both a public portfolio and my own learning tool. The public side shows how I think about AI capability building. The private side is FOS: the implementation lab where the patterns are tested, broken, fixed, and turned into reusable notes.

The core idea is simple:

• The model is not the workflow.
• A capability is not learned until it has an artifact, a failure test, and a handover path.
• A public page should make the transferable pattern visible without exposing private source material.

How to use this site

• Read the pages as a curriculum, not as finished marketing copy.
• Use the learning goal to understand what each capability is meant to prove.
• Use the practice loop as the next exercise.
• Use the proof artifact to check whether the learning is real yet.
• Use the current status to separate what is already demonstrated from what is still planned.

Learning roadmap

• AI capability as a system: the map of memory, task contracts, tools, scripts, checks, logs, and adoption rituals.
• Adoption through artifacts: how teams learn by building inspectable domain artifacts.
• Model-agnostic agentic workflows: how to keep durable workflows above any single model provider.
• Multimodel orchestration: how to route work across local, hosted, cheap, fast, and high-judgment paths.
• Guardrails: how to define boundaries before an AI system touches users or sensitive workflows.
• LLM evaluation: how to measure quality with a task-specific dataset instead of vibes.
• Red-teaming: how to attack the system before a real user or adversary does.
• Agent authority and secrets: how to keep delegated authority scoped, brokered, and auditable.
• Citizen-facing LLM architecture: how the pieces compose for a high-stakes public-service style use case.
• Handover: how a prototype becomes something another person can operate.
• Worked example: Danish citizen-facing LLM: a running architecture sketch that composes the capability pages.

Current priority

The next private builds should happen in this order:

• Build one guardrails layer in front of a real FOS endpoint and block a known prompt-injection prompt.
• Build a small LLM evaluation harness with Danish and English prompts, half of them adversarial.
• Run one scoped red-team pass against the local Spark model or a routed FOS workflow.
• Update the worked example with the evidence from those runs.
• Add handover notes so the system can be operated without relying on memory.

Publishing rule

Every source file starts with frontmatter:

• public: true or false; only true renders into the static site.
• title: the navigation and metadata title.
• summary: one sentence used in page listings.
• source_tickets: tickets that tie the public page back to the work.
• learning_stage: where the capability is in the learning cycle.
• proof_status: what evidence exists right now.

Pages can be useful before they are finished, but they must be honest about their status. If the proof is missing, the page should say so and name the next build.