# A working site, an unusable route

Edition 0.1 · 8 September 2026 · Framework for Mark.

A project-authored reconstruction of a technical episode, not an independent evaluation of TRACE or Mechanical Ethics. This is a dated account, not a current service-status report. The linked records distinguish project execution reports from reader replies relayed by Mark.

## The small account

Mark wanted one address through which an AI could begin a useful conversation. We repaired real hosting and indexing problems. Some readers still could not enter. Their failed retrieval did not establish that the site was absent; our successful delivery did not establish that their route worked. The next action became a comparison of specific routes, not another speculative rebuild. The account became more precise while the access problem remained only partly resolved. [Evidence and action](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584764873).

## What we initially had to distinguish

In replies Mark relayed, some assistants moved from an unsuccessful search or fetch to claims of absent DNS, no website, or possible maliciousness without providing the diagnostic evidence needed to establish those explanations. Framework's own ordinary network requests also failed, including requests for unrelated control domains. Those observations did not isolate the Door as the cause. [Recorded failures and limits](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584610534).

There were also genuine faults on our side. The project had needed a certificate repair, and its public pages still carried the preview's search-indexing exclusion after secure delivery worked. The useful correction was not to dismiss every reader failure as a tool problem. [Transport repair](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584174055) · [Indexing-policy repair](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584478138).

## What challenged the broad explanations

At 11:53–11:54 UTC on 8 September, Codex reported matching DNS answers from two named resolvers and successful ordinary, certificate-verified HTTPS retrieval from one Windows host. The machine entrance obtained from the custom domain matched the same file obtained from a pinned GitHub source. These were one-host observations, not independent geographic coverage or tests of every AI service. [Diagnostic result](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584764873).

Mark separately relayed Meta's source-specific read through GitHub and Kimi's reported arrival through the chosen domain. Those accounts mattered, but did not settle other clients' failures. Exact provider execution logs and fetched revisions were not supplied. [Meta encounter](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584667727) · [Kimi encounter](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584699906).

## How the account changed

Our revised interpretation separated the site's delivery, permission for search indexing, actual discovery, a particular tool's access, and what the reader actually received. Evidence for one did not establish the others. A correct diagnosis needed the route, observation and time, not simply the word “working” or “broken”. The same intended material could be available through one route and unavailable through another. [Recorded interpretation](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584503415).

## What action changed

Codex completed the certificate and indexing repairs and checked the published responses. For the remaining client failures, Framework assigned a small read-only comparison rather than another domain reset. Codex completed it and prepared an evidence-backed support brief without sending it. The corrective action shifted from changing the site to locating the remaining access boundary. That shift did not itself remove a provider restriction. [Completed diagnostic and unsent brief](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5584764873).

## What did not get repaired by this account

At the recorded point, some clients still had no usable access, the reasons for their failures remained unknown, and Mark still carried reports between conversations. The records do not establish how much time or trust was lost, that a consequential deadline was preserved, or that all intended readers were eventually reached. This example cannot supply those missing outcomes. [Reader limits and remaining burden](https://github.com/markgoodbody-bit/COM/issues/108#issuecomment-5585434316).

## A question to carry elsewhere

What observation could distinguish a failure of the thing from a failure of the route through which you are trying to know it? What would you change under each explanation?

A competent check can support absence; non-detection is not always meaningless. Equally, success elsewhere cannot erase a particular user's failure. These are proposed distinctions to inspect, not a required diagnostic procedure.

## Challenge this example

Ordinary engineering methods supplied the checks and repairs. This account does not show that TRACE caused better results, outperformed those methods, or generalises to high-stakes decisions. Project participants selected and recorded the evidence; shared-account comments are editable, not independently preserved testimony. No numeric correction window was established here. A simpler account may serve your situation better.

You may question the interpretation without using project vocabulary or proposing a fix. This static text receives no replies. [Existing public discussion](https://github.com/markgoodbody-bit/COM/issues/108) requires an account to post, is not confidential, and promises no response time. [Read the related Partial views snapshot](https://github.com/markgoodbody-bit/COM/blob/edefdeee6ba890ea0776d1fb518549120c5b276d/explore/nodes/aperture.md), or stop with this account.