Research notes for practical AI systems.

Most readiness conversations open in the wrong place. They start with a model, a platform, or a budget line, then work backwards toward a problem. The teams that actually get value tend to start somewhere quieter and far less impressive-sounding: a single workflow they can describe from beginning to end.

A team isn't ready for AI because it has picked a model or signed a contract. It's ready when it can name five things without hand-waving — the workflow, the user, the risk, the source material, and the point where a human checks the output. If any one of those is vague, the project isn't ready. It's a guess with a deadline.

That test is deliberately unglamorous, and that's the value of it. It rules out the loose experiments that quietly consume budget and produce demos nobody ships. The useful starting question is narrow: which work is repetitive, text-heavy, backed by evidence, and safe enough to improve with machine assistance? That is where the first build belongs.

The NIST AI Risk Management Framework is useful precisely because it treats AI risk as something an organisation governs, maps, measures and manages — not a checkbox bolted on at the end. For a small team, that doesn't have to mean a compliance department. It can be a single page: who owns this workflow, what sources the system may use, where outputs get reviewed, and the situations where the system should not be used at all.

Generative tools make this more important, not less. The same system can draft, summarise and classify — and invent. A real readiness review asks whether the organisation can inspect the source material and correct the output, not just whether the model writes a fluent paragraph. Fluency is cheap now. Correctability is the asset.

We treat readiness as an engineering and operations problem before it's a product decision. Before proposing a build, we want to see the workflow as it actually runs today: the documents, the decisions, the handoffs, the questions that keep coming back, the quality checks, and the known failure modes.

More often than not, the first deliverable should be a better map, not a better prompt. Once the map exists, the AI opportunity gets easier to scope, easier to price, and — just as importantly — easier to reject when it isn't worth building.

A lot of AI tooling frames continuity as a logistics problem: how do we move conversation history from one product into another? It's a tidy question with a tidy answer, and it's usually aimed at the wrong target. A transcript is a container. The useful work inside it is smaller, denser, and far more durable than the conversation that carried it.

Think about what you'd actually want to keep from a good working session: the business context, the standard operating procedures, the prompts that worked, the workflows and automations you settled on, the decisions you made and the reasons behind them, the templates worth reusing. Pull those out and you can review them, correct them, and reuse them — without dragging every turn of a chat along for the ride.

Markdown isn't magic, and that is the entire point. It reads as plain text, versions cleanly, copies into almost any AI tool, and opens in a wide range of editors and knowledge systems. The CommonMark specification matters here because it gives Markdown a stable reference point instead of a dozen incompatible dialects.

The test for any knowledge pack is simple: does it stay useful when the tool that made it disappears? If your operating knowledge is trapped behind a proprietary workspace database, the answer is no. If it's portable text with its sources attached, the answer is yes.

AI Knowledge Pack is, deliberately, not a chat migration tool. It converts useful AI work into portable Markdown so a person can carry the knowledge into the next tool, the next meeting, the next repository, or the next operating process.

The review step is where the value is protected. Extracted knowledge should keep its source references and flag anything uncertain for a human to check. Portability without review doesn't help anyone — it just moves confusion around faster.

When a tool handles customer research, internal procedures, founder notes or operational decisions, the question that matters is quietly structural: who has to be trusted for this to function? If the first thing the tool does is upload your file, the answer is everyone in the path — the application, the host, the storage layer, the analytics stack, and every integration along the way.

Local-first architecture narrows that boundary. It doesn't make risk disappear, but it changes the default. Files can be read and transformed on your own machine before anyone decides whether the output should be shared at all. The decision to send data becomes an explicit choice instead of an automatic one.

It's worth being precise here, because the term gets oversold. Local-first does not automatically mean secure, compliant, or fit for every regulated workflow. A browser app still depends on code quality, dependency hygiene, and the security of the device it runs on.

The honest claim is narrower, and stronger for being narrow: if there's no upload path, no account system, and no remote processing call, then there are simply fewer places where your source documents can leave your machine during normal use. Fewer doors is not zero doors — but it's a real difference, and it's one you can verify.

For AI Knowledge Pack v0.1.0, local-first is a constraint, not a tagline. Files are processed in the browser, the generated Markdown is previewed by the person who created it, and the zip is downloaded locally.

Future AI API integrations may well be useful — but they should be explicit choices the user makes, not defaults hidden in the plumbing. Sensitive workflow tools earn trust the same way every time: by showing where data goes, and by making the quiet, default path the safest one.