Module 8: Capstone Project — Be Mercado's Architect Through a Change

7. Plan the evolution and the documentation

Overview

This is step 6, the last before assembling the deliverable, and it's the one that separates launching a feature from closing the craft. In the previous steps you derived the attributes, structured the teams, communicated the decision, and led its adoption. But a change doesn't end when it's launched: it stays alive, and the architect has to plan how it's going to evolve —what to build now and what to defer— and leave the documentation that survives so the change doesn't depend on a single head. By the end of this lesson you'll have the last two artifacts of the dossier: the evolution plan (what's now, what's sacrificial, what's deferred leaving the seam) and the measurement of how the documentation raises the bus factor of the new surface. This step integrates two modules —M6 (designing for change) and M7 (documentation that survives)— because in practice they go together: planning the evolution without documenting it is leaving the plan in your head, and documenting without planning the evolution is documenting a photo that has already started to change.

This matters because the two opposite mistakes —over-building and under-building— are equally expensive, and Mercado's change invites both. The temptation of over-engineering: since the goal says "grow 10x", building today all the machinery of the 10x —catalog sharding, multi-region, a massive ingestion pipeline— before there's a single external seller generating that volume, spending months on scaling for a traffic that doesn't exist yet. The opposite temptation, under-engineering: launching the surface without leaving the seams for the 10x, so that when the volume arrives, adding them is a very expensive refactor. The architect who plans for change avoids both: they build today the seams expensive to add later, put sacrificial versions of what depends on data that doesn't exist yet, and defer what no one needs yet —leaving the seam so as not to get trapped—. And then they document it so the whole team can maintain it, not just whoever built it.

Connection with the module: this lesson does step 6 of the thread and contributes the M6 and M7 pieces to the capstone. It receives its input from step 5 (what was really adopted and who owns what: you don't plan the evolution of the imagined, but of what was built and adopted) and from step 2 (the governing scalability-vs-cost conflict, which is precisely what the evolution plan resolves by deferring the expensive 10x). Its output closes the dossier that lesson 8 will assemble and defend before the VP. The frontier is respected: reversibility and the last responsible moment as a technique were taught in architecture-decisions; here it's the mental posture of the craft —how the architect sequences and documents—. And the specific documentation tools stay out; here the principle (docs-as-code) and the criterion (the bus factor).

The one who builds a house for a family that's going to grow

Think of a couple building their first house, knowing they'll have children but without knowing how many or when. They have three ways to face the uncertain future.

The first, over-engineering: building today an eight-bedroom mansion "just in case". They spend all their money and years of construction on empty rooms that maybe will never fill, with a loan that drowns them while they wait for a family that may be two children, not six. They built for an imagined future that may not arrive, and the cost of that future crushes them in the present.

The second, under-engineering: building a two-bedroom house with load-bearing walls placed such that it's impossible to add a floor or a room later. When the second child arrives, they discover that expanding means demolishing half the house. They saved today and tied themselves down: the future arrived and didn't fit.

The third, the one a good architect does: building today the house the family needs now —two or three bedrooms—, but leaving the seams that make it cheap to grow later: foundations that hold a second floor, pipes with spare capacity, a wall known not to be load-bearing so it can be torn down when needed. They don't build the rooms that don't exist yet (that would be the mansion), but they do leave the terrain prepared to build them when the child arrives. And something more: they leave the plans where the next owner (or the mason of the expansion) will find them, so they know which wall can be torn down and which not —without having to guess—.

Mercado's architect facing "grow 10x" is that couple. Over-engineering would be building today all the infrastructure of the 10x before there are external sellers generating that volume —the empty mansion—. Under-engineering would be launching the surface without leaving the seams, so scaling later demands demolishing —the house that can't be expanded—. The craft is building the expensive seams today, putting simple and disposable versions of the uncertain, deferring what no one needs yet, and leaving the plans (the documentation) so the team can grow the house without guessing. This lesson executes that plan and measures how much the plans raise the bus factor.

Worked example: the evolution plan and the bus factor

We're going to execute two things. First, classify each candidate of the change into what to build now, what to make sacrificial, and what to defer, according to three signals: whether the v1 launch needs it (not the future 10x), whether it's a seam expensive to add later, and whether deciding it well demands data we don't have yet. Second, measure the bus factor of the new surface before and after leaving the documentation that survives.

# Capstone step 6: plan the EVOLUTION (what first, what is deferred, what seams I leave)
# and leave DOCUMENTATION that survives. Neither over- nor under-engineering: I build today the
# seams that are expensive to add later, and I defer what depends on data that doesn't exist yet.

# Each candidate of the change, with three signals:
#   goal_critical      -> does the v1 LAUNCH need it (not the future 10x)?
#   expensive_later    -> is it a seam that's expensive to add later (structural)?
#   high_uncertainty   -> does deciding it well require data we don't have yet?
candidates = {
    "seller_api_contract_and_gateway": dict(goal_critical=True,  expensive_later=True,  high_uncertainty=False),
    "seller_platform_team_boundary":   dict(goal_critical=True,  expensive_later=True,  high_uncertainty=False),
    "platform_as_service_contracts":   dict(goal_critical=True,  expensive_later=True,  high_uncertainty=False),
    "seller_risk_scoring":             dict(goal_critical=True,  expensive_later=False, high_uncertainty=True),
    "listing_ingestion_pipeline":      dict(goal_critical=True,  expensive_later=False, high_uncertainty=True),
    "catalog_sharding_for_10x":        dict(goal_critical=False, expensive_later=True,  high_uncertainty=True),
    "multi_region_availability":       dict(goal_critical=False, expensive_later=True,  high_uncertainty=True),
    "seller_analytics_dashboard":      dict(goal_critical=False, expensive_later=False, high_uncertainty=False),
}


def classify(c):
    # Expensive structural seam needed already: build NOW (last responsible moment).
    if c["goal_critical"] and c["expensive_later"]:
        return "NOW"
    # The launch needs it but we don't know yet how to do it well: simple, throwaway
    # version NOW, with a seam to replace it (sacrificial architecture).
    if c["goal_critical"] and c["high_uncertainty"]:
        return "SACRIFICIAL_NOW"
    # The launch doesn't need it: defer. If it's expensive to add, leave the seam.
    if c["expensive_later"]:
        return "DEFER_WITH_SEAM"
    return "DEFER"


plan = {name: classify(sig) for name, sig in candidates.items()}
buckets = {"NOW": [], "SACRIFICIAL_NOW": [], "DEFER_WITH_SEAM": [], "DEFER": []}
for name, b in plan.items():
    buckets[b].append(name)

print("=== Evolution plan of the change (what first, what is deferred) ===")
labels = {
    "NOW": "NOW (structural seam, expensive and needed already)",
    "SACRIFICIAL_NOW": "NOW, SACRIFICIAL (simple today, replaced with real data)",
    "DEFER_WITH_SEAM": "DEFER leaving the seam (the launch doesn't ask for it; expensive to add)",
    "DEFER": "DEFER (YAGNI: no one needs it yet)",
}
for b in ("NOW", "SACRIFICIAL_NOW", "DEFER_WITH_SEAM", "DEFER"):
    print(f"\n{labels[b]}:")
    for name in buckets[b]:
        print(f"  - {name}")

print()
print(f"NOW: {len(buckets['NOW'])}   SACRIFICIAL: {len(buckets['SACRIFICIAL_NOW'])}   "
      f"DEFERRED: {len(buckets['DEFER_WITH_SEAM']) + len(buckets['DEFER'])}")
print("I build the 33% that is structural seam, not the 100% of the imagined future.")

# --- Documentation that survives: the bus factor of the new surface, before/after ---
# How many people understand each critical module. The system's bus factor is the
# MINIMUM (the weakest link): how many would have to leave to leave it unmaintained.
critical_modules = ["seller_api", "seller_onboarding", "listing_ingestion", "payout_processing"]

# BEFORE documenting: the knowledge lives in the head of whoever built it.
knowers_before = {
    "seller_api": 1, "seller_onboarding": 2,
    "listing_ingestion": 1, "payout_processing": 1,
}
# AFTER docs-as-code (onboarding README + C4 + ADR versioned next to the code):
# the whole team can maintain any module; the onboarding stops depending on a head.
knowers_after = {
    "seller_api": 4, "seller_onboarding": 4,
    "listing_ingestion": 3, "payout_processing": 3,
}

bf_before = min(knowers_before[m] for m in critical_modules)
bf_after = min(knowers_after[m] for m in critical_modules)

print()
print("=== Bus factor of the sellers surface ===")
print(f"{'module':<20}{'before':>7}{'after':>9}")
for m in critical_modules:
    print(f"{m:<20}{knowers_before[m]:>7}{knowers_after[m]:>9}")
print(f"\nSystem bus factor (the minimum): {bf_before} -> {bf_after}")
print("Before, if one person leaves, the change's surface is left unmaintained (bus factor 1).")
print("The documentation that survives (docs-as-code) raises the bus factor: the change stops")
print("depending on a single head. That's closing the craft, not just launching the feature.")

What to expect. Running it:

=== Evolution plan of the change (what first, what is deferred) ===

NOW (structural seam, expensive and needed already):
  - seller_api_contract_and_gateway
  - seller_platform_team_boundary
  - platform_as_service_contracts

NOW, SACRIFICIAL (simple today, replaced with real data):
  - seller_risk_scoring
  - listing_ingestion_pipeline

DEFER leaving the seam (the launch doesn't ask for it; expensive to add):
  - catalog_sharding_for_10x
  - multi_region_availability

DEFER (YAGNI: no one needs it yet):
  - seller_analytics_dashboard

NOW: 3   SACRIFICIAL: 2   DEFERRED: 3
I build the 33% that is structural seam, not the 100% of the imagined future.

=== Bus factor of the sellers surface ===
module               before    after
seller_api                1        4
seller_onboarding         2        4
listing_ingestion         1        3
payout_processing         1        3

System bus factor (the minimum): 1 -> 3
Before, if one person leaves, the change's surface is left unmaintained (bus factor 1).
The documentation that survives (docs-as-code) raises the bus factor: the change stops
depending on a single head. That's closing the craft, not just launching the feature.

Read the evolution plan first, which is the mental posture of the craft made into a list. Of the eight candidates, only three are NOW —the Seller API contract and its gateway, the seller_platform team boundary, and the platform-as-a-service contracts—. Why those three and not more? Because they're the structural seams expensive to add later: if you don't define the Seller API contract from day one, changing it once there are integrated third parties is very expensive; if you don't create the owning team now, the Conway maneuver doesn't happen; if you don't define the platform-as-a-service contracts, the surface is born coupled. These three are the pipes and the foundations of the house: you put them in while building, or you demolish to add them later. Notice the last line of the plan: the architect builds 33% that is structural seam, not 100% of the imagined future. There's the defense against over-engineering: most of what "could" be built isn't built now.

Now the two SACRIFICIAL ones, which are the finest nuance of the craft. seller_risk_scoring (evaluate an external seller's risk) and listing_ingestion_pipeline (the pipeline that imports the products) are needed by the launch —you can't open to third parties without evaluating their risk or without importing their products—, but deciding them well demands data you don't have yet: you don't know what fraud patterns the real sellers will have or what volume of listings will arrive. The answer isn't to wait (the launch needs them) or to build the definitive version blind (that would be guessing): it's to put a simple and disposable version today —a basic scoring with manual rules, a simple synchronous ingestion— knowing it'll be replaced when the real data arrives, and leaving the seam to replace it painlessly. This is module 6's sacrificial architecture: building something knowing it'll be thrown away, not through carelessness but by strategy —it's cheaper to build simple today and replace with data than to build complex today with assumptions—.

And the three DEFERRED ones, where the governing conflict of step 2 lives. catalog_sharding_for_10x and multi_region_availability are the machinery of the 10x: expensive, structural, but the launch doesn't need them —at opening, there's no 10x of traffic yet—. Here is where the architect resolves the scalability-vs-cost conflict (57, the one that governed the change): they don't build the expensive infrastructure of the 10x today (protecting cost), but leave the seam to add it when the volume justifies it (protecting future scalability). It's "defer with seam", not "abandon": they abstract the data access so putting in sharding later isn't demolishing. And seller_analytics_dashboard is pure YAGNI —no one needs it yet, nor is it expensive to add later—, so it's deferred without more. The complete plan is the posture of the craft: build the seams (3 now), put sacrificial versions of the uncertain (2), and defer the expensive future leaving it the seam (3) —neither the empty mansion nor the house that can't be expanded—.

The second half of the output is the documentation. The bus factor measures how many people would have to leave for a critical module to be left unmaintained —it's the weakest link: the minimum over the modules—. Before documenting, the new surface has bus factor 1: seller_api, listing_ingestion, and payout_processing are understood by a single person (whoever built them), so if that person leaves, the most important change of the year is left orphaned. After leaving the documentation that survives —docs-as-code: the README that onboards, the C4 of step 4, and the ADR-021 versioned next to the code— the bus factor rises to 3: the whole team can maintain any module because the knowledge stopped living in a head and moved to where anyone finds it. Notice the ADR of step 4 wasn't only communication in the moment: it was an investment in the bus factor —the documented why is what lets someone who wasn't in the room maintain the surface without guessing—. Raising the bus factor from 1 to 3 is the difference between a change that depends on a person and one the organization owns. That's closing the craft.

Deep dive: why the evolution and the documentation close the thread together

It's worth understanding why this step joins two modules that seem different —designing for change (M6) and documenting (M7)— and why it's the natural close of the thread.

The evolution and the documentation are the same question seen in two tenses. Planning the evolution is asking "how is this going to change in the future?". Documenting so it survives is asking "who is going to understand this in the future to be able to change it?". Both point at the same horizon —the system after today— and one without the other is lame. A brilliant evolution plan that lives only in the architect's head doesn't survive the architect leaving: when the 10x volume arrives and it's time to put in the deferred sharding, no one will know the seam was planned or where. And an impeccable documentation of a system that wasn't designed to change documents a cage. That's why they go together: the architect designs the seams for change and documents where they are and why, so whoever comes after can use them.

This step is where the previous artifacts prove their second value. The C4 and the ADR of step 4 were produced to communicate in the moment, but here they reveal their lasting value: they're exactly the documentation that raises the bus factor. The ADR-021, which in step 4 explained the why to the VP and the dev, in step 6 is what lets a new engineer understand why the gateway exists and why the sharding was deferred —without that ADR, the bus factor wouldn't rise, because the why would still be in a head—. This is the beauty of the thread: each artifact serves twice. The ranking of step 2 justified the structure and then fed the rollout; the C4 and the ADR of step 4 communicated and then documented. The capstone doesn't produce disposable artifacts; it produces pieces that work throughout the whole lifecycle.

And here the thread connects with itself, because designing for change is accepting the thread will be traveled again. The evolution plan recognizes that the business's goals will change —Mercado opened to external sellers today; tomorrow it'll want something else—, and that when they do, the architect will travel the whole thread again: derive the new attributes, restructure if needed, communicate, lead, evolve. The documentation you leave today (the C4, the ADRs) is the starting point of that next journey: the next architect won't start from zero, they'll start by reading what you left. That's why documenting so it survives isn't the end of the craft; it's preparing the next cycle. The architect who plans for change and documents isn't closing a project: they're leaving the system ready for the craft to be exercised on it again, by someone else, with less pain.

An honest nuance about the models. The classification of the eight candidates uses a judgment (is it goal-critical?, is it expensive to add later?, is there data uncertainty?) that's debatable case by case —someone could argue that risk_scoring is so critical it deserves more than a sacrificial version—, and that debate is healthy: the model makes the judgment explicit so it can be argued. The bus factor numbers (1 knower before, 3-4 after) are illustrative; what's robust is the shape —knowledge concentrated in one head is bus factor 1, and the documentation that onboards raises it—. The model captures the criterion of the craft, not an exact measurement.

Common mistakes

Building the machinery of the 10x before there's 10x (of over-engineering). What happens: since the goal says "grow 10x", the team builds today the catalog sharding, the multi-region, and the massive ingestion pipeline —months of work— before there's a single external seller generating that volume. The launch is delayed, the cost skyrockets (violating the cost attribute), and half of that infrastructure turns out badly sized because it was built with assumptions, not real data. Why it happens: "grow 10x" sounds like "we have to build for 10x now". How to spot it: if you're building capacity for a volume that doesn't exist yet, you're filling the mansion with empty rooms. How to fix it: defer the machinery of the 10x leaving the seam (abstract the data access so sharding goes in later without demolishing); build it when the real volume justifies it, not when the goal mentions it.

Launching without leaving the seams (of under-engineering). What happens: the team, avoiding over-engineering, launches the surface as simple as possible but without leaving the terrain prepared —the data access hardcoded such that putting in sharding later demands rewriting half the service, the ingestion coupled such that scaling it is demolishing—. When the volume arrives, adding the deferred is a very expensive refactor. Why it happens: "not building the future" is confused with "not leaving room for the future". How to spot it: if you deferred something expensive but can't add it later without rewriting, you didn't leave the seam. How to fix it: "defer with seam" isn't "defer plainly" —the three-bedroom house is built with foundations that hold a second floor—; defer the implementation, but leave the abstraction (the contract, the extension point) that makes it cheap to add.

Leaving the knowledge in a head and calling it "I'll document it later" (of bus factor 1). What happens: the sellers surface is built and launched, but the documentation —the README, the updated C4, the ADRs— is left "for when there's time", and the knowledge lives only in whoever built it (bus factor 1). When that person leaves or gets sick, the most important change of the year is left orphaned and no one knows why the gateway exists or where the sharding seam is. Why it happens: documenting feels like work that doesn't deliver visible value, always postponable. How to spot it: if a single critical module is understood by a single person, your bus factor is 1, no matter how much code there is. How to fix it: docs-as-code —the README, the C4, and the ADR versioned next to the code, updated in the same PR that changes the system—; you already have the ADR from step 4, it just needs to live in the repo. Documenting isn't an extra at the end; it's what turns a one-person change into an organization's change.

Exercises

Exercise 1 — Classify a new candidate. Leadership proposes adding "push notifications to external sellers when one of their products sells". Apply the three signals (does the v1 launch need it?, is it a seam expensive to add later?, does deciding it well demand data we don't have?) and classify it (NOW / SACRIFICIAL_NOW / DEFER_WITH_SEAM / DEFER). Justify.

See solution

Applying the three signals:

Does the v1 launch need it? Probably not. An external seller can start selling without receiving an instant push for every sale —they can check their panel—. It's an experience improvement, not a requirement for the surface to work. (goal_critical = False.)
Is it a seam expensive to add later? No. Adding push notifications later is additive: you consume the "sale" event (which already exists) and send it via notifications (which is already a platform service). It doesn't shape the structure or require demolishing anything. (expensive_later = False.)
Does it demand data we don't have? Not especially. (high_uncertainty = False.)

Classification: DEFER (YAGNI). With goal_critical = False and expensive_later = False, it falls in the same bucket as seller_analytics_dashboard: defer plainly, because no one needs it yet and adding it later is cheap. There's no need even to leave a special seam, because the sale event and the notifications service already exist —the seam is already there—.

The nuance the exercise teaches: not everything deferred needs "leaving the seam" explicitly. catalog_sharding_for_10x is deferred with seam because adding it later is expensive and structural (you have to prepare the data access). The push notifications are deferred without a special seam because adding them later is cheap and additive. The rule: leave the seam when the deferred is expensive to add; if it's cheap, defer it plainly. Confusing it leads to over-engineering (preparing elaborate seams for things that will be added easily anyway).

Exercise 2 — The governing conflict, resolved in time. Step 2 detected that scalability vs cost (57) was the conflict that governed the change. Explain how the evolution plan of this lesson resolves that conflict without the architect having to choose an absolute winner —and why that's different from "resolving the trade-off" in the sense of the sister guide—.

See solution

The evolution plan resolves the scalability-vs-cost conflict by distributing it in time, not by choosing a winner. The conflict was: "grow 10x" (scalability) against "don't triple the bill" (cost). At a single moment, those two pull head-on —building for 10x today costs a lot—. But the evolution plan reconciles them with the axis of time:

Today it protects cost: it defers catalog_sharding_for_10x and multi_region_availability (the expensive machinery of the 10x), because the launch doesn't have that volume yet. You don't spend on scaling for a traffic that doesn't exist. Cost wins in the present.
Tomorrow it protects scalability: it leaves the seam to add that machinery when the real volume justifies it. The architect doesn't paint themselves into a corner; the 10x is still possible without demolishing. Scalability wins in the future, when it truly matters.

So the architect didn't have to say "scalability yes, cost no" (which would have angered the CFO) or "cost yes, scalability no" (which would have killed the flagship goal): they said "cost now, scalability when the volume asks for it", and both goals are fulfilled at their right moment.

Why it's different from "resolving the trade-off" of the sister guide. architecture-decisions-and-tradeoffs resolves a trade-off by deciding the balance point with a matrix —how much of each attribute, with which technical option—. That's still necessary when the time comes to put in the sharding (which sharding strategy?, what cost does it accept?). What step 6 does is different and complementary: it sequences the conflict in time (what now, what later) so as not to have to resolve it all today. The posture of the craft (M6) says "defer the decision until the last responsible moment, when you have data"; the deciding method (sister guide) says "when that moment arrives, this is how you choose the balance". The capstone does the first; it refers to the sister guide for the second.

Exercise 3 — The bus factor and the ADR. The bus factor of the surface rose from 1 to 3 thanks to the documentation that survives. Explain specifically what role the ADR-021 (from step 4) plays in raising that bus factor —what knowledge it captures that the code and the C4 don't— and what would happen to the bus factor if only the code and the diagram were left, without the ADR.

See solution

The ADR-021 raises the bus factor because it captures the why, which neither the code nor the C4 contains. The code says how the surface is built (it's read from the repository). The C4 says what pieces there are and how they connect (the current photo). But neither of the two says why: why the gateway exists (third-party security), why an owning team was created (scalability, the friction 21→7), why catalog_sharding was deferred (the cost-vs-scalability conflict), which seams are intentional and which aren't. That why is exactly the knowledge that lives in the head of whoever decided —and that, without the ADR, leaves with that person—.

What would happen with only code and diagram, without the ADR. The apparent bus factor would rise a bit (more people can read the code and the C4), but the real bus factor would still be fragile, because whoever inherits the surface would understand the what and the how but not the why —and without the why, they fall into the two traps of module 3: either they undo good decisions through not understanding them (remove the gateway "because it's unnecessary complexity", without knowing it protects third parties), or they respect decisions out of superstition ("I won't touch the deferred sharding, there must be a reason", without knowing which). An engineer who can read the code but doesn't know why it's this way can't evolve the system safely —they can only maintain it blind—, and that's a deceptive bus factor: it seems there's someone to maintain it, but no one can change it well.

The integration lesson: the ADR you produced in step 4 to communicate is, in step 6, the piece that truly raises the bus factor —more than the code or the diagram—, because it's the only one that preserves the reasoning. That's why the capstone insists on the ADR: it's not bureaucracy of the moment, it's the investment that makes the change survive people. Documenting the why (docs-as-code, the versioned ADR) is what turns "the team can read the code" into "the team can evolve the system" —which is the bus factor that matters—.

Summary and next step

In this lesson you did step 6 of the deliverable: planning the evolution and leaving the documentation that survives. With the family that builds a house to grow —neither the empty mansion (over-engineering) nor the house that can't be expanded (under-engineering), but today's house with the seams for tomorrow— you understood the mental posture of the architect who designs for change. You executed it: of eight candidates, three are built now (the expensive structural seams), two are sacrificial (simple versions of what depends on data that doesn't exist), and three are deferred (the machinery of the 10x, with seam, resolving the cost-vs-scalability conflict in time). And you measured that the documentation that survives —docs-as-code: the README, the C4, and the ADR versioned— raises the bus factor of the surface from 1 to 3, turning a change that depends on a head into one the organization owns. You understood that the evolution and the documentation are the same question in two tenses, that the artifacts of step 4 serve twice (communicate and document), and that documenting so it survives is preparing the next journey of the thread.

Before moving on you should be able to: classify a change's candidates into now / sacrificial / deferred-with-seam / deferred, with the three signals; explain how the evolution plan resolves the governing conflict in time; distinguish over- from under-engineering and the "defer with seam" that avoids both; and explain why the ADR raises the bus factor more than the code or the diagram.

What follows is the final step: assembling and defending. You already built the six pieces of the deliverable —the framed assignment, the attributes, the structure, the C4 and the ADR, the rollout, the evolution and the documentation—. Lesson 8 is the project: you're going to assemble everything in the architect's integrated dossier, measure it against a rubric, write the script of the conversation with the VP that sews the craft back to the business, and —with that— close the whole guide, pointing toward where to go next in the ecosystem. It's where you verify that the six pieces weren't six projects, but a single movement.

Resources

Martin Fowler — "Sacrificial Architecture" — the essay that names the strategy of building something knowing it'll be replaced; the direct backing of the two sacrificial pieces of the plan (risk scoring and ingestion).
Martin Fowler — "Yagni" — "You Aren't Gonna Need It", the principle that holds up deferring the machinery of the 10x until the volume justifies it, and the defense against over-engineering of this step.
arc42.org — the architecture documentation template that integrates the C4 and the ADRs in a living document; the framework of the documentation that survives and raises the bus factor.
Simon Brown — "Software architecture as code / docs-as-code" — the principle of versioning the diagrams and the decisions next to the code (not in a wiki that rots), which is what makes the change's documentation survive time and people.

← Previous6. Lead the rollout without authority Next →8. Project: be Mercado's architect facing the change