ArchitectMentor Weekly · 12–18.10.2026

Green does not mean complete

A component may respond, a pipeline may be green and an agent may return valid JSON. None of those facts yet proves that the user received an outcome or that the proposed change was authorised.

Edition for review · 5 materials · PL / EN

Start with the decision
From the editor

Name the outcome before reading the lights

The exercise begins with a system whose components look healthy while work has stopped between acceptance and completion. This is a common perspective error: architecture is measured from the inside while the user stands at its end.

The Foundation arranges evidence in four layers: process life, dependency readiness, work progress and the user outcome. The anti-pattern shows how easy it is to aggregate green components into false confidence.

The same idea returns in AI agents and the delivery supply chain. An action gateway stops an operation the model cannot authorise. A GitHub Actions lockfile moves an invisible dependency change into review — but the review still has to happen. Automation without a decision owner merely loses accountability faster.

Reading order

In this edition

  1. 01 · Practice

    Every light is green. Why can the customer not complete the operation?

    Separate component health, asynchronous progress and the outcome promised to the user.

    Read the material →
  2. 02 · Foundations

    Business-process availability: from green components to a user outcome

    An evidence ladder: liveness, readiness, progress and a safe end-to-end probe.

    Read the material →
  3. 03 · Anti-pattern

    Every component is green, therefore the service works

    Why an average of health checks is not evidence that a process completed.

    Read the material →
  4. 04 · Architect + AI

    An AI agent can propose a change. Who authorises execution?

    An action gateway, independent authorisation and an audit trail for agent effects.

    Read the material →
  5. 05 · Architecture in motion

    GitHub Actions lockfiles move invisible changes into review

    The 14 October public preview: pinned commits, transitive dependencies and an update process.

    Read the material →
Team discussion

Three questions for an architecture review

These are prompts for team practice, not reports of particular incidents.

A decision has a condition. Who confirms completion?

Separate the person operating the control, the reviewer of evidence and the role that releases the launch gate.

A replica exists. Which promise does it improve?

Name a measurable goal: read performance, data freshness or failover. A copy of data does not select the objective for the architect.

Every layer retries three times. Who owns the attempt budget?

Set one end-to-end deadline and retry owner; local retries must not amplify load without control.

Conferences and workshops

Continue the discussion with practitioners

The events catalogue lists upcoming conferences and workshops and marks details that require another check.

Browse events