Scar Tissue

Overview

This gets its own topic for two reasons. It is the most under-modelled force in architectural proposals — and handled well, it is the only organisational constraint in this module that actively helps you.

Organisational scar tissue is the constraint a prior failure imposes on present proposals, carried as reaction rather than as recorded history. Nobody can cite it. Everybody responds to it.

Why it cannot be argued with

Ordinary risk aversion is general: an organisation is cautious about everything. Scar tissue is specific — the organisation is cautious about this shape of thing, and relaxed about others.

The property that makes it difficult is that the caution has no stated reason. The event was never written up, so there is no account to engage with. What arrives instead is:

objections that are technically weak but socially strong
questions that seem disproportionate to the risk being discussed
a proposal that stalls with no stated reason
the sentence “we tried that”

You cannot address an argument nobody has made. And the caution is not irrational — it is a correct inference from an event the organisation declined to examine. Treating it as unreasonable is both wrong and the fastest way to confirm that you do not understand where you work.

The diagnostic

Ask about history explicitly, early, and of several people:

“What has been tried here before in this area? What happened to it?”

Three things make this work. Ask it in your first weeks, when being new licenses the question. Ask several people separately — the differences between their accounts are the most informative part, because they reveal which aspects are contested and which are settled. And ask about outcomes rather than opinions: “what happened” rather than “what went wrong”, which invites narrative rather than blame and gets better answers.

Four responses, in order of effectiveness

graph TD
  A["<b>1 · Name it first</b><br/>address the prior failure<br/>before anyone raises it"] --> E["Objection becomes<br/>evidence of homework"]
  B["<b>2 · Build the mechanism</b><br/>that would have caught it"] --> F["The strongest argument<br/>available to you"]
  C["<b>3 · Make the difference<br/>concrete</b><br/>not 'this is different'"] --> G["Checkable rather<br/>than reassuring"]
  D["<b>4 · Let the sceptic<br/>co-author the safeguard</b>"] --> H["They defend the<br/>threshold they set"]

  classDef move fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef best fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef good fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  class A,C,D move
  class B,F best
  class E,G,H good

Four responses. The second is the real one: a mechanism is worth more than any argument, because it is the only thing that addresses the actual inference the organisation drew.

Name it first. A proposal that addresses the prior failure before anyone raises it converts the strongest objection in the room into evidence that you did your homework. Raised by someone else, the same point is a challenge you are answering under pressure. Section 4 treats this as a pitch technique; here it is the strategy that makes the pitch possible.

Build the mechanism that would have caught it. The real answer, and the one that distinguishes an architect from a persuasive person. The question is not “why will this not fail the same way?” but “what would have detected the last failure, and is it in this design?” If a system degraded quietly, an automatic regression gate is the answer — and it is worth more as an argument than as engineering.

Make the difference concrete. “This is different” is what everyone says and means nothing. What works: that failed because nothing measured whether it was still working; here is the measurement, here is who owns it, here is the threshold, and here is what happens automatically when it is crossed. Checkable rather than reassuring.

Let the sceptic co-author the safeguard. Module 2’s elicitation technique, spent where it has most leverage. Their objection becomes the threshold, and people rarely veto their own numbers.

The asymmetry: it is also your best lever

The reframe worth taking from this topic.

Scar tissue creates demand for exactly the rigour you want to introduce. An organisation that has watched a system fail quietly will fund an evaluation practice, a regression gate and an observability plan that a confident organisation would refuse as overhead.

So the prior failure is not only the obstacle to your proposal — it is the business case for the parts of your proposal that are hardest to justify. Module 6’s evaluation section is a difficult sell in the abstract and an easy one to an organisation with this history.

That changes how you frame the whole initiative: not “this is safe, trust us”, but “here is the mechanism that the last attempt lacked, and it is the reason to do this now”.

2023, in full

The facts, in the case’s own words: in 2023 the company shipped a machine-learning feature for smart routing. It worked at launch. Over months it degraded. Eventually it was switched off, quietly, without an announcement. Nobody brings it up in meetings. Everybody remembers. And: you will not find this in any document; you will find it in how people react when you propose something that sounds similar.

What Ivan Petrov infers, rationally. A system that produced plausible output, degraded without anyone noticing, and was removed without examination. He has eight years of tenure and owns the monolith. His inference is that this organisation cannot detect slow quality decay and does not discuss it afterwards. Nothing about that is unreasonable.

The four responses, applied.

Name it first. The architecture proposal opens with 2023 — what happened, what was absent, and what is different — before anyone asks. Section 4’s pitch requires the objection answered before it is raised.

Build the mechanism. The automatic regression gate from Module 6: weekly measurement against the golden set, a defined threshold, and an automatic release block that fires on its own authority rather than requiring someone to raise a concern. Section 1’s culture topic established why that matters here — in an organisation where a failure could not be discussed, a mechanism that needs no messenger is the only reliable form of risk reporting.

Make the difference concrete. Not “we will monitor it”. Rather: the 2023 feature had no measurement of ongoing quality; this one has 300 curated questions, a stated correctness floor, a confident-error ceiling ten times tighter, a named owner in Maya Ortiz, and a release gate. And — crucially — Module 6’s arithmetic showing that the originally-specified 3-point trigger sat inside the measurement’s noise floor, with the correction to four repetitions. That detail is what makes the claim credible to a sceptic, because it demonstrates the safeguard was checked rather than asserted.

Let him co-author it. Ivan sets the regression threshold. Module 2 named him as reviewer on the confident-error ceiling for exactly this reason.

And the lever. The evaluation practice in Module 6 — a golden set costing real curation time from Grace Adeyemi’s team, four evaluation runs per cycle, a batch spend line — is a hard sell in a company with no spare capacity. 2023 is the reason it gets funded. The scar is the business case.

Feeds the workbook

The rubric requires the prior failure to be treated as an active constraint on the proposal you build later in this module, not as history. So write what it changes: which mechanism exists because of it, who co-authors the threshold, and what the proposal says about it in its opening rather than its appendix.

→ One question remains, and the honest version of this material has to include it. — Expectations, and when to leave