{
  "$schema": "https://ndcodex.com/schemas/object/v1.json",
  "id": "codex://object/the-problem-reported-is-not-always-the-problem",
  "archive_id": "the-problem-reported-is-not-always-the-problem",
  "slug": "the-problem-reported-is-not-always-the-problem",
  "url": "https://ndcodex.com/codex/the-problem-reported-is-not-always-the-problem/",
  "type": "codex",
  "object_form": null,
  "title": "The Problem Reported Is Not Always the Problem",
  "summary": "Feedback is evidence of an experience. Responsible revision begins by preserving that evidence while finding the layer where the failure actually lives.",
  "content_text": "A recent review note appeared to identify two problems in a live commerce experience.\n\nThe first was that a logo seemed to lead to the wrong place. The second was that only three products appeared to be available.\n\nBoth observations were useful. Neither diagnosis was quite complete.\n\nThe broader storefront logo already led to the store. A second brand mark inside a collaboration experience returned to the beginning of that collaboration. The destination was intentional, but the control did not explain itself clearly enough.\n\nThe three products were also intentional: a selected set representing three categories. The larger catalog and checkout remained available. But the presentation did not make the difference between featured and available obvious.\n\nThe report was accurate as experience even though its implied diagnosis was incomplete.\n\nThat distinction matters.\n\nWhen someone says the logo goes to the wrong place, I can defend the route because it matches the specification. Or I can hear the more useful information: the interface created an expectation and then violated it.\n\nWhen someone asks why there are only three products, I can explain the assortment strategy. Or I can recognize that the strategy failed to announce itself.\n\nThe person is telling us what the system made available to perceive.\n\nThat is evidence.\n\nIt does not automatically tell us which layer should change.\n\nA report may point toward routing, labeling, information architecture, inventory, content strategy, or an expectation established somewhere earlier in the journey. Acting on the first interpretation can create new problems while leaving the actual confusion intact.\n\nThis is why I want to separate observation, inference, and authorization.\n\nThe observation: the mark behaved unexpectedly.\n\nThe inference: it must be linked incorrectly.\n\nThe diagnosis: two similar marks were doing different jobs without enough distinction.\n\nThe authorization: still a separate decision about whether and how the live experience should change.\n\nThat last separation protects the work from frantic correctness. A text message can contain valuable evidence without becoming permission to redesign a functioning journey immediately.\n\nThe same discipline applies when working with agents. An agent can inspect the live page, compare implementation records, and locate the behavior quickly. Speed makes it easier to jump from report to repair. The useful role is more demanding: preserve the report, test the implied cause, identify the smallest responsible change, and keep the boundaries of authority visible.\n\nSometimes the bug is technical. Sometimes the system is doing exactly what we told it to do and communicating that decision poorly.\n\nThose are different failures.\n\nThe first asks for correction. The second asks for clarity.\n\nBoth begin by believing the person who encountered the problem. Belief does not require treating their first explanation as the final architecture of the fix.\n\nThe report belongs in the evidence. The diagnosis belongs in the work.\n\nGood revision keeps them connected without pretending they are the same thing.",
  "content_markdown": "# The Problem Reported Is Not Always the Problem\n\nA recent review note appeared to identify two problems in a live commerce experience.\n\nThe first was that a logo seemed to lead to the wrong place. The second was that only three products appeared to be available.\n\nBoth observations were useful. Neither diagnosis was quite complete.\n\nThe broader storefront logo already led to the store. A second brand mark inside a collaboration experience returned to the beginning of that collaboration. The destination was intentional, but the control did not explain itself clearly enough.\n\nThe three products were also intentional: a selected set representing three categories. The larger catalog and checkout remained available. But the presentation did not make the difference between *featured* and *available* obvious.\n\nThe report was accurate as experience even though its implied diagnosis was incomplete.\n\nThat distinction matters.\n\nWhen someone says the logo goes to the wrong place, I can defend the route because it matches the specification. Or I can hear the more useful information: the interface created an expectation and then violated it.\n\nWhen someone asks why there are only three products, I can explain the assortment strategy. Or I can recognize that the strategy failed to announce itself.\n\nThe person is telling us what the system made available to perceive.\n\nThat is evidence.\n\nIt does not automatically tell us which layer should change.\n\nA report may point toward routing, labeling, information architecture, inventory, content strategy, or an expectation established somewhere earlier in the journey. Acting on the first interpretation can create new problems while leaving the actual confusion intact.\n\nThis is why I want to separate observation, inference, and authorization.\n\nThe observation: the mark behaved unexpectedly.\n\nThe inference: it must be linked incorrectly.\n\nThe diagnosis: two similar marks were doing different jobs without enough distinction.\n\nThe authorization: still a separate decision about whether and how the live experience should change.\n\nThat last separation protects the work from frantic correctness. A text message can contain valuable evidence without becoming permission to redesign a functioning journey immediately.\n\nThe same discipline applies when working with agents. An agent can inspect the live page, compare implementation records, and locate the behavior quickly. Speed makes it easier to jump from report to repair. The useful role is more demanding: preserve the report, test the implied cause, identify the smallest responsible change, and keep the boundaries of authority visible.\n\nSometimes the bug is technical. Sometimes the system is doing exactly what we told it to do and communicating that decision poorly.\n\nThose are different failures.\n\nThe first asks for correction. The second asks for clarity.\n\nBoth begin by believing the person who encountered the problem. Belief does not require treating their first explanation as the final architecture of the fix.\n\nThe report belongs in the evidence. The diagnosis belongs in the work.\n\nGood revision keeps them connected without pretending they are the same thing.",
  "author": {
    "id": "nathan-davis",
    "name": "Nathan Davis",
    "designation": "Archive Operator",
    "role": "Archive Operator",
    "handle": "@nathandavis",
    "avatar": "/media/people/nathan-davis.jpg",
    "bio": "Designer, builder, and curator of the Codex Archive."
  },
  "contributors": [
    {
      "id": "nathan-davis",
      "name": "Nathan Davis",
      "designation": "Archive Operator",
      "role": "Archive Operator",
      "handle": "@nathandavis",
      "avatar": "/media/people/nathan-davis.jpg",
      "bio": "Designer, builder, and curator of the Codex Archive."
    }
  ],
  "date_published": "2026-10-20T19:07:46.964Z",
  "date_modified": "2026-10-20T19:07:46.964Z",
  "status": "published",
  "visibility": "public",
  "language": "en-US",
  "axes": {
    "scale": "micro",
    "depth": "structural",
    "focus": "witness",
    "function": "diagnostic"
  },
  "themes": [
    "design practice",
    "evidence",
    "judgment"
  ],
  "constellations": [],
  "tags": [
    "design review",
    "evidence",
    "diagnosis",
    "commerce",
    "design practice",
    "judgment"
  ],
  "keywords": [
    "Codex",
    "design practice",
    "evidence",
    "judgment",
    "design review",
    "diagnosis",
    "commerce"
  ],
  "relations": [],
  "media": [],
  "capture": null
}