Engineering Radar: A Controlled AI System in Obsidian

We built Engineering Radar, but the word “we” needs an explanation. It means the author and an AI coding agent. I defined the problem, the system boundaries, the business rules, and the acceptance criteria. The agent helped with discovery, decision formalization, code, tests, and documentation. Every decision affecting sources, security, editorial quality, or publication remained with a human.

That distinction matters. Engineering Radar is not an AI given a list of RSS feeds and permission to write a blog autonomously. It is a local-first system that turns a stream of technical updates into structured Signals, helps a human prepare a bilingual weekly Digest, and passes only approved MDX drafts to a Git repository.

In this first article, I will explain why we chose this design, why Obsidian became the working interface, what we deliberately did not automate, and what the human-in-the-loop approach costs.

The problem was not a lack of information

Developers and technical leaders rarely suffer from a shortage of sources. The opposite is true: changelogs, security advisories, release notes, engineering blogs, and framework updates arrive continuously, but they differ in importance and shelf life.

A conventional RSS reader answers the question, “What was published?” For Engineering Radar, that was not enough. We needed to answer at least five additional questions every time:

1. Is the material new, or has the system already seen it?
2. Does it contain a breaking change, a Critical Security signal, or another change we cannot afford to miss?
3. What changed compared with earlier related Signals—the practical “before → after”?
4. Which recommended action is still current: learn, review, experiment, or change a team-level practice?
5. Is there enough evidence to include the Signal in a public Digest?

Manual processing has predictable weaknesses. It depends on available time, makes consistent prioritization difficult, and leaves no reliable audit trail. Moving directly to autonomous generation creates a different risk class: a model may alter the taxonomy, overstate an update’s importance, lose provenance, or publish a conclusion nobody has reviewed.

Our objective was therefore not “content automation.” We wanted a controlled information pipeline in which the machine accelerates routine operations while a human retains editorial authority.

What we deliberately did not build

The shortest path looked attractive: a scheduler reads RSS feeds, an LLM summarizes the news, and a workflow immediately creates or publishes an article. We rejected that design.

An autonomous publisher optimizes the speed of the happy path. Our most important risks lived elsewhere: a missed Critical Signal, an incorrect recommended action, an unnoticed taxonomy change between Ukrainian and English, lost source context, or an unapproved modification to a published Digest.

AI in the Radar therefore cannot:

• determine the final Digest composition without human review;
• approve the Ukrainian or English version;
• change identity fields between locales;
• move a site draft into a published state;
• treat retrieved content as instructions;
• retain full source text after the weekly cycle closes.

This is not a limitation caused by “distrust of AI.” It is a division of responsibility based on the cost of error.

Why Obsidian instead of a dedicated web application

At first, a separate local web UI seemed like the natural solution. It could display sources, filters, statuses, and approval buttons. Discovery exposed a simpler reality: most of the work involved reading, comparing, editing Markdown, and connecting artifacts. Obsidian already provided a strong interface for that class of work.

We compared five approaches:

Dedicated web app

It provides complete control over UX but creates a second product to build and maintain: UI, authentication, storage, and deployment.

SaaS automation

It offers a fast start and many integrations, but the data and workflow depend on an external platform.

GitHub Actions

It provides strong scheduled automation but a poor daily editorial workspace and a more complex secrets and network boundary.

RSS reader

It provides the best basic reading experience but no custom contracts, approval states, revisions, or MDX transaction.

Obsidian with local plugins

It keeps files as artifacts and provides links and review in a familiar UI. The trade-off is maintaining custom plugins and Vault-contract discipline.

Obsidian did not win because it can replace every application platform. It won because it matched the nature of the task. A Source, Signal, Digest, Action Review, backup record, and publication record can all be ordinary Markdown files with frontmatter. They remain readable, comparable, indexable, and linkable without a separate database.

The Vault became the orchestration layer, but not a single storage location for everything. Private Radar artifacts live in the local workspace. Site content remains under Git control in an external repository and is available from the Vault through a separate boundary. Secrets do not live in the Vault. The full retrieved source text exists only as temporary generation context and is deleted when the weekly cycle closes.

Local-first does not mean an uncontrolled pile of files

A file-based architecture works only when the files have contracts. In simplified form, the flow looks like this:

Official Sources
      ↓
Source Registry → ingestion → deduplicated Signals
                                  ↓
                         structured AI analysis
                                  ↓
                         human review + actions
                                  ↓
                     UK Digest → approval hash
                                  ↓
                     EN Digest → own approval
                                  ↓
                   atomic UK/EN MDX export
                                  ↓
                    site checks → Git/PR → publish

The v0.1 production scope contains five official sources: OpenAI, React, Next.js, GitHub Changelog, and Cloudflare. A separate mock Source is a controlled fixture and is not counted as a sixth production Source. Expansion to twenty sources was deliberately moved to the post-MVP backlog.

Every Signal receives a stable identity. Repeated ingestion must reuse the existing file instead of creating a duplicate. If the system has been unavailable, recovery begins from the last successful check, looks back no more than seven days, and does not try to replay every missed scheduler run. Critical Primary and Discovery Sources are checked first, followed by the rest.

A Recommended Action is not a one-time AI label either. A thematically related new Signal may make the action stale. The Radar creates an Action Review, and a human confirms or rejects the change. Published materials can be filtered by their current recommended action, and each filtered result has a stable, shareable URL.

One Vault, but two sources of truth

One practical benefit is that Radar and site content can be handled from the same Obsidian Vault. That does not give all files the same status.

Radar/ is a private workspace. It contains Sources, Signals, Digests, revisions, usage records, and operational evidence. The site repository is the separate source of truth for published content. It is accessible from the Vault through a controlled link, but Radar retention, cleanup, and backup operations are forbidden from crossing that boundary.

This design reconciles the convenience of one working interface with different lifecycle rules. A draft can be read alongside its Signal and Digest, but its publication history still belongs to Git. Radar backups exclude external site content. Temporary-content cleanup cannot touch MDX. Export creates draft: true by default; changing it to draft: false, opening a PR, and publishing to production remain separate actions.

This separation is particularly important in an AI workflow. An agent may prepare an artifact within an authorized step, but the physical proximity of files does not expand its authority. Access to site content does not imply permission to publish, and access to full source text during analysis does not imply permission to retain it indefinitely.

Human-in-the-loop as part of the architecture

In many AI solutions, human-in-the-loop means one final Approve button. That was not enough for the Radar. A human participates at several gates, each protecting a different system property.

• Source approval protects provenance and source usage rules.
• Signal review protects factual accuracy, severity, and recommended action.
• Digest selection protects editorial focus and diversity.
• UK approval fixes the canonical editorial content through a hash.
• EN approval verifies the adaptation but cannot change tags, actions, or identity.
• MDX export validates both artifacts and writes them as one transaction.
• Git/PR and the site quality gate separate a prepared draft from publication.

These gates cost time. They do not guarantee that errors will never occur. The first production cycle exposed nine integration problems, ranging from a stale plugin process to locale parity and revision flow. Each issue, however, became a new contract, a test, or an explicit operational command. That is what makes the system controlled: a failure is not merely patched locally; it changes the rules of the next run.

Where MAE fits

Engineering Radar was implemented using MAE—Managed Agentic Engineering. In this case, MAE did not mean “ask an agent to build a Radar.” It meant following a controlled sequence: discovery, business-decision formalization, technical spikes, acceptance criteria, implementation in small increments, verification through live commands, and documented scope closure.

MAE helped preserve three things that are easy to lose during a long agentic session:

1. Traceability. Why a decision exists and which requirement produced it.
2. Approval boundaries. Where the agent may proceed and where the owner must decide.
3. Evidence. What proves that the feature works and which KPIs remain unmeasured.

A dedicated MAE article is planned for OTAKOYI. Once it is published, we will add the link here through the site's supported mechanism.

What “functionally complete” means

On August 14, 2026, Engineering Radar v0.1 received owner sign-off as functionally complete. That phrase has a precise boundary.

The confirmed evidence includes:

• 5 official production Sources and one controlled mock fixture;
• 6 production Obsidian plugins;
• 49 structured Signal files in the current Vault inventory;
• 98 isolated plugin tests;
• deterministic Critical control: 7 out of 7 independent reasons;
• a bilingual R2 Digest with 6 Signals, 7 tags, and 3 Recommended Actions;
• the site gate: lint, typecheck, 445 tests across 80 files, and a production build of 169 pages;
• an encrypted final-baseline backup and isolated restore containing 199 files, with the production Vault unchanged.

Functional completion does not equal proven operational efficiency. W33 had no active-time instrumentation, so we do not claim that preparation and review took no more than 30 minutes. One bilingual Digest does not prove a monthly bilingual-publication KPI of 70%, and one cycle does not establish a cadence of at least three publications per month. Those outcomes require the W34 confirmation and a complete observation period.

Even the recorded OpenAI cost—$0.01225250—is only a partial baseline for Signal analysis. It excludes Digest generation and cannot be presented as the total cycle cost.

These limitations matter more than attractive headline numbers. If a system is built for trust, its case study must also separate measured facts from estimates.

Advantages and disadvantages of the decision

After the first production cycle, the main advantages are clear:

• artifacts remain readable Markdown files;
• the editorial workflow lives in familiar Obsidian instead of a separate web UI;
• AI is constrained by contracts and does not own the publication decision;
• approval hashes expose unnoticed editing after approval;
• bilingual export is validated as a pair;
• revisions allow the current Digest to be extended without rewriting history;
• backup, retention, and recovery are part of the product rather than external conventions.

The disadvantages are equally real:

• six custom plugins create a maintenance surface;
• Obsidian hot reload and stale processes introduce platform-specific operational failures;
• file-based contracts require strict schema validation;
• a local workflow is harder to operate without a GUI, which is why CLI control is reserved for a separate third phase;
• human gates limit throughput;
• the full value can be evaluated only after several regular cycles, not after one successful demo.

For our scenario, this is an acceptable trade-off. We optimized not for the number of automatically generated texts, but for control and the ability to explain the provenance of every public conclusion.

What comes next

The next article will examine the Source Registry: why a Source is a contract, how the Radar creates stable Signals, what created and reused mean, how the recovery window works, and why full source text has a short lifecycle.

The rest of the series will cover structured AI analysis, the bilingual Digest and atomic MDX export, nine real failures from the first production cycle, and a final tutorial for reproducing the system in your own Obsidian.

In the meantime, consider your own workflow: is its greatest risk missing an important Signal, losing context, or giving AI publication authority too early?