5. The implicit attributes nobody asked for

Overview

By the end of this lesson you'll know how to see the requirements written nowhere and that, nevertheless, will decide whether your system is considered a success or a disaster —because they exist, everyone counts on them, and no one asks for them—. So far you worked with the explicit: the business put goals on the table (lesson 2), you turned them into measurable scenarios (lesson 3), you filtered the ones that shape the architecture (lesson 4). All that work starts from something someone said. But there's a whole class of quality attributes no one says because everyone takes them for granted, like air: that an order, once charged, isn't lost or duplicated (data integrity); that every money transaction can be traced (auditability); that personal data is protected (privacy); that if something fails, the system recovers without losing data (recoverability); that if something breaks at 3am, someone finds out (observability). They're the tacit contract of the domain: what's expected of any system that handles money and third-party data, whether the stakeholder says it or not. You'll execute a comparison between what Mercado's explicit goals named (five attributes) and what the domain always demands, and you'll see the gap: six more attributes, none asked for.

This matters because the implicit attributes are the number-one source of the catastrophes that make a competent architect look bad. The system can meet perfectly everything the business asked for —it scales 10x, survives Black Friday, shields the payment data— and still be a failure, because one day an order got charged twice (data integrity failed, which no one asked for), or because the regulator asked "show me the trail of this transaction" and there was no trail (auditability failed, which no one asked for), or because a service was down for three hours and no one found out until the customers complained (observability failed, which no one asked for). The VP never wrote "the system must be auditable" in their list of goals, the same way no one buying a house writes "make sure the roof doesn't fall" —it's taken for granted—. But when the roof falls, it's no use saying "you didn't ask for the roof to hold up". The architect who only delivers the explicit delivers a system full of expensive surprises waiting to explode. This lesson's skill is discovering the implicit before it explodes: knowing the tacit contract of the domain and bringing it to the surface, so it's designed on purpose instead of discovered in a crisis.

Connection with the module: this lesson covers the blind spot the previous ones explicitly left open. Lesson 2 warned it: the mapping of goals captures what the business names, and there are attributes with a zero score that don't appear because no goal pushes them. This lesson goes looking for exactly those. The implicit attributes you discover here are treated the same as the explicit ones of the previous lessons: they become measurable scenarios (lesson 3) and are classified as ASR or not (lesson 4) —in fact, many implicit ones are among the heaviest ASRs, as you saw with GDPR—. And they feed the conversations to come: in lesson 6 you'll have to explain to the VP why the project costs more than they imagined, and a good part of that "more" is the implicit attributes they didn't ask for but have to be built. The frontier stays: here you discover which implicit attributes the domain demands; how the level of each one is decided and how it competes with the explicit ones is architecture-decisions's method.

The house that "no one asked not to flood"

Think about it with whoever buys a house. The couple gives the architect their wish list: three bedrooms, open kitchen, a garden, lots of natural light, a study. It's a complete list —for them—. Now imagine the architect builds exactly that list, and only that list: three beautiful bedrooms, a gorgeous open kitchen, a garden, light, a study. And then the first storm comes and the house floods, because no one asked for good drainage. And in summer it's an oven, because no one asked for thermal insulation. And the electrical installation has no ground, because no one asked for it. And there are no smoke detectors, because no one asked for them. The couple is furious —"you built a house that floods!"— and the architect, absurdly, defends themselves: "you didn't ask for it not to flood". They're literally right and completely wrong. No one asks for the house not to flood, not to be an oven, not to electrocute you, not to burn without warning —because they're the tacit contract of what "a house" means—. A house architect who doesn't include them without being asked isn't an architect: they're someone who draws bedrooms.

Notice what distinguishes the good house architect: they don't wait to be asked for the drainage, the insulation, the ground, and the smoke detectors —they put them in because they know what the craft and the local climate demand—. Their knowledge of the domain (what houses are like, what this climate is like, what the code requires) tells them which implicit requirements come with the territory, even if the client never mentions them. And they do one more thing, which is the other half of the craft: they tell the client, so they understand why the house costs what it costs. "Besides your three bedrooms, I included storm drainage, insulation, and a grounded electrical system —you didn't ask for them, but a house without them floods, is an oven, and is dangerous—; that explains part of the budget." The software architect does exactly this: they know the tacit contract of their domain —what any system that handles money, personal data, third-party integrations demands— and bring those requirements to the surface, both to design them and to explain why the system costs more than the business, looking only at its wish list, imagined.

Worked example: the gap between what's asked and what's expected

We'll execute the comparison. On one side, what Mercado's explicit goals named —the five attributes from the lesson 2 ranking—. On the other, the tacit contract of a marketplace that handles money and third-party data: the attributes expected even if no one asks for them. The gap —what the domain demands and the goals didn't name— is the list of implicit attributes the architect has to discover.

# The IMPLICIT attributes: no one asks for them, but everyone takes them for granted.
# We compare what the EXPLICIT goals named against what a
# marketplace that handles money and third-party data must ALWAYS meet.

# What Mercado's explicit goals named (the lesson 2 attributes):
explicit = {"scalability", "availability", "security", "performance", "cost"}

# The domain's "tacit contract": what's expected even if no one asks for it.
expected_by_domain = {
    "security":       "obvious, but also everything below",
    "data_integrity": "a charged order CANNOT be lost or duplicated",
    "auditability":   "every money transaction must be traceable",
    "privacy":        "personal data protected (GDPR / local law)",
    "usability":      "a vendor must be able to operate without calling support",
    "recoverability": "if something fails, it recovers without losing data",
    "observability":  "if something breaks at 3am, someone finds out",
}

implicit_gap = [a for a in expected_by_domain if a not in explicit]

print("Attributes NO ONE named but EVERYONE expects:")
for attr in implicit_gap:
    print(f"  - {attr:<15} {expected_by_domain[attr]}")

print()
print(f"Explicit goals -> {len(explicit)} named attributes.")
print(f"The domain demands -> {len(implicit_gap)} MORE attributes, none asked for.")
print(f"Delivering only what's asked = delivering {len(implicit_gap)} expensive surprises later.")

What to expect. Running it:

Attributes NO ONE named but EVERYONE expects:
  - data_integrity  a charged order CANNOT be lost or duplicated
  - auditability    every money transaction must be traceable
  - privacy         personal data protected (GDPR / local law)
  - usability       a vendor must be able to operate without calling support
  - recoverability  if something fails, it recovers without losing data
  - observability   if something breaks at 3am, someone finds out

Explicit goals -> 5 named attributes.
The domain demands -> 6 MORE attributes, none asked for.
Delivering only what's asked = delivering 6 expensive surprises later.

Read the list and notice something uncomfortable: the business named five attributes, and the domain demands six more no one named. The stakeholder's wish list, which seemed complete, covered less than half of what the system really needs. And notice what the six implicit ones are —they're not technical whims of the architect, they're things any reasonable person assumes a marketplace has—. No one buying on Mercado thinks "I hope my order isn't charged twice"; they simply take it for granted (data integrity). No one selling thinks "I hope if the system goes down it doesn't lose my day's sales"; they assume it (recoverability). The regulator doesn't ask for auditability at the start; they demand it the day they investigate a fraud, and by then it has to have existed all along. Each of those six is a real and often heavy requirement, and none appeared on the business's list because they're too obvious for the user —so obvious no one says them—.

Stop at the last line, because it's the module's warning: delivering only what's asked is delivering six expensive surprises later. Imagine the architect who takes the business's list as the complete specification and builds exactly the five explicit attributes, ignoring the six implicit ones. Their system scales, survives Black Friday, shields the payment data —it meets everything they asked for— and is still a time bomb. One day, because of a badly-handled retry, an order gets charged twice (data_integrity failed): furious customers, refunds, damaged reputation. Another day, the regulator asks for the trail of a suspicious transaction and it doesn't exist (auditability failed): a legal problem. Another, a service is down for hours without anyone noticing because there are no alerts (observability failed): silent loss of sales. None of those catastrophes violates the explicit specification —all violate the tacit contract—. And each one could have been prevented by designing the implicit attribute from the start, when it was cheap, instead of discovering it in a crisis, when it's very expensive. The gap of six attributes is, literally, a list of six ways to look bad despite having met everything asked for.

Notice a detail in the code that teaches about the craft: security appears on both lists. It was in the explicit goals (the business did ask to "shield the payment data") and it's in the domain contract. But even there there's a trap: the business asked for security for one concrete thing (the card data), while the domain demands it more broadly —isolation between vendors, protection against injection, access control across the whole API—. An attribute can be explicit and have an implicit part: the business named the tip of the iceberg (payment data) and the architect has to see the rest (everything else "security" implies in a multi-tenant marketplace). That's why security didn't enter the gap (it was already named) but still hides implicit requirements within itself. Discovering the implicit isn't just "which attributes are missing entirely"; it's also "which parts of a named attribute the business didn't imagine".

An honest nuance about the method. The expected_by_domain list of this example was written by the architect from their knowledge of the domain —marketplaces that handle money—. It's not a universal truth that comes from a formula: for a video game, the tacit contract would be another (low latency, anti-cheat, fairness); for a medical system, another (patient safety, clinical traceability, certifications). The value of the exercise isn't in this particular list, but in the discipline of asking yourself, for each domain, what its tacit contract is and comparing it against what the business named. The tool doesn't discover the implicit by magic; it forces you to make explicit your knowledge of the domain and confront it with the wish list. Where that knowledge comes from —from experience, from the sector's standards, from talking to whoever already built something similar, from the applicable regulations— is part of the craft that's cultivated. What the lesson gives you is the habit of looking for the gap, not a list that works for everything.

Deep dive: where the tacit contract comes from, and how to bring it to the surface

It's worth understanding where the implicit attributes come from, because knowing their sources is what lets you discover them in a new domain where you don't have the list memorized.

From the business domain. Each industry has expectations that come with the territory. A system that handles money implies data integrity (not losing or duplicating transactions), auditability (tracing every movement), and often regulatory compliance (PCI-DSS, anti-money-laundering). A system that handles personal data implies privacy and the rights the law grants (access, deletion, portability). A system that handles third parties (like Mercado's external vendors) implies isolation and fairness between them. The first place to look for the implicit is asking "what kind of things does this system handle —money, personal data, health, identity, third parties— and what does each one demand by default?".

From real operation. Many implicit attributes don't come from the business but from the harsh reality of operating a system in production. Observability (if something breaks, you have to find out), recoverability (systems fail; they have to be able to come back), maintainability (someone will have to change this in two years) aren't asked for by any business stakeholder because they live in the world of whoever operates, not whoever uses. The operations team, the on-call team, the one who's going to maintain the system —those are the silent stakeholders whose needs are pure implicit attribute—. Asking "who's going to operate this at 3am, and what do they need not to go crazy?" brings half the gap to light.

From what the user assumes without saying. Usability, accessibility, that things "just work" —the user doesn't ask for them because they take them for granted—. No one writes in a requirements list "make sure the interface isn't confusing"; it's assumed. These implicit ones are discovered by putting yourself in the end user's shoes and asking "what would this person expect without even thinking about it?".

Now, the hardest part, which is the other half of the craft: how to bring the implicit to the surface without it sounding like you're inflating the project. Because there's a real risk: if the architect arrives with a list of six attributes that "no one asked for but have to be built", the business can hear "the architect wants to make the project more expensive and longer with things we don't need". The way to avoid it is the same one the house architect used: explain each implicit one in terms of the concrete catastrophe it prevents, in the business's language. Not "we need auditability" (it sounds like a technical whim), but "we need to be able to trace every transaction, because the day the regulator investigates a fraud —and it will happen— not being able to show them the trail is a fine and a legal problem". Not "we need observability", but "we need automatic alerts, because today if a service goes down at night we find out from the angry customers on Twitter, and each hour down is lost sales". Each implicit attribute is justified not by its technical name but by the disaster it avoids —and that disaster, told in money or in risk, is something the business understands and approves—. Discovering the implicit is half; selling it as prevention of concrete catastrophes is the other. That sale is exactly the conversation of lesson 6.

And the frontier. Discovering that Mercado needs auditability is this lesson's work. How much auditability —every field, every access, retention for how many years, at what cost— and how it weighs against other attributes (full auditability can add latency and storage cost) is a decision with trade-offs resolved with architecture-decisions's method. Here you bring the implicit attribute to the list; there you decide its level. What matters in this lesson is that the attribute reaches the list —because an attribute that was never named is never designed, and an attribute that's never designed is the future's expensive surprise—.

Common mistakes

Treating the stakeholder's list as the complete specification (of literalness, again). What happens: the architect receives the business's goals, treats them as everything the system needs, and builds exactly that —without auditability, without observability, without recoverability, because they weren't on the list—. The system meets the specification and fails the tacit contract. Why it happens: the business's list looks complete (it's what the business knows to ask for), and it's convenient to treat it as the total scope. How to spot it: if your specification doesn't include any attribute the business didn't name, you didn't look for the implicit. How to fix it: for each system, explicitly build the list of the domain's tacit contract (what it handles: money, data, third parties) and compare it against what's asked —the gap is your list of implicit ones—.

Discovering the implicit but not communicating it (of silent discovery). What happens: the good architect does know that auditability and recoverability are needed, and designs them, but doesn't tell anyone —they put them in "under the hood"—. Then, when the project costs more and takes longer than the business imagined, the business doesn't understand why, and the architect looks like the one who "over-engineered". Why it happens: the architect assumes the implicit ones are so obvious they don't need explaining, forgetting that for the business they were not obvious (that's why they didn't ask for them). How to spot it: if the business is surprised by the cost or the time of the project, you didn't communicate the implicit. How to fix it: make each implicit attribute and its justification (the catastrophe it prevents) visible before building it —so the cost has a reason the business approved, not a surprise—.

Inflating the implicit into paranoia (of over-engineering). What happens: at the opposite extreme, the architect discovers the tacit contract and takes it to absurdity —audits every click, replicates in five regions "just in case", designs for a disaster this business will never face—. They turn "not losing orders" into a mission-critical high-availability system for a startup that bills little. Why it happens: once you start thinking about what can go wrong, it's easy not to stop. How to spot it: if you're designing for catastrophes this business, at its scale, will almost certainly never live, you overdid it. How to fix it: each implicit attribute is also prioritized and bounded by its level (lesson 3) and decided against its cost (the decisions guide); "auditable" doesn't mean "audit everything forever", it means "audit what the real risk justifies". The implicit has to be discovered and sized —bringing it to the list isn't putting it all at the maximum (lesson 7)—.

Exercises

Exercise 1 — The tacit contract of another domain. A team is going to build a messaging app for a hospital, for doctors and nurses to coordinate about patients. The client's wish list says: "fast messages, groups by area, notifications, conversation history". Name at least four implicit attributes the domain (health + communication about patients) demands that aren't on the list, and explain the catastrophe each one prevents.

See solution

Four implicit attributes of the domain (health + communication about patients), with the catastrophe each one prevents:

• Privacy / confidentiality (HIPAA compliance or equivalent). The messages contain patients' medical information, which is among the most protected by law. Catastrophe it prevents: a leak of clinical data, which besides harming the patients is a regulatory violation with severe fines and legal liability for the hospital.
• Auditability / traceability. In health, who said what and when about a patient can have clinical and legal consequences. Catastrophe it prevents: that in the face of a medical incident (a badly-communicated indication) there's no way to reconstruct what was communicated, leaving the hospital with no defense and unable to learn from the error.
• Delivery reliability (message data integrity). A message about a patient that "gets lost" or arrives late can be dangerous. Catastrophe it prevents: that an urgent indication ("stop this medication") doesn't arrive or arrives duplicated and confused, with direct harm to the patient.
• Availability / recoverability. A hospital operates 24/7; the app can't "be down for a while". Catastrophe it prevents: that the system goes down during an emergency and the staff can't coordinate, exactly when they need it most.

(Others valid: usability for non-technical staff under stress; role-based access control; data retention and deletion per regulation.) The lesson: none was on the wish list ("fast messages, groups, notifications, history"), and all are heavy requirements that will decide whether the app is usable in a hospital or a legal and clinical risk. The tacit contract of "communication about patients" is enormous and almost all implicit.

Exercise 2 — The explicit attribute with an implicit part. Mercado's business asked to "shield the payment data" (security, explicit). Argue why, even being an explicit attribute, it hides implicit requirements the business didn't imagine, and name three parts of "security" the business didn't ask for but the domain demands.

See solution

"Shield the payment data" is the tip of the security iceberg: the business named the part it consciously worries about (that the card numbers aren't stolen), but "security" in a multi-tenant marketplace that opens to third parties implies much more, and those parts are implicit —the business didn't imagine them because it doesn't think like an attacker or an architect—. Three parts of security the domain demands and the business didn't ask for:

• Isolation between vendors (multi-tenancy security). By opening to external vendors, each one must see only their data —their sales, their customers, their products—. The business asked to protect the buyers' payment data, but didn't think about one vendor not being able to spy on another vendor's data. A cross-tenant leak is a different disaster and the business didn't name it.
• Access control and authorization across the whole API. Opening a public API means anyone can try to call it; each endpoint needs to verify who is calling and what they're allowed. The business asked to protect payment data, it didn't design the permission model of an API open to thousands of third parties.
• Protection against abuse: rate limiting, input validation, injection prevention. A public API is a target: brute-force attacks, injection, denial of service. The business didn't ask for "make sure they don't take down our API with an attack"; it assumes it.

The deep dive's lesson, concretely: an attribute can be explicit and have an enormous implicit body. The architect who reads "shield the payment data" and only encrypts the card numbers met the explicit letter and left open three fronts the domain considers mandatory. Discovering the implicit isn't just looking for absent attributes; it's also looking inside each named attribute and seeing which parts the business didn't imagine.

Exercise 3 — Discover it and sell it. You're Mercado's architect. You discovered that the external-vendors project needs observability (alerts when something fails) and auditability (transaction trail), neither of them asked for by the business. The VP, looking at the budget, asks you: "why is it so expensive? I only asked to open the platform to vendors". Write how you'd explain those two implicit attributes in their language, without jargon, in a way that gets them approved instead of cut.

See solution

The key is to justify each implicit one by the concrete catastrophe it prevents, in money and risk, not by its technical name. Something like:

"You're right that you only asked to open the platform, and that's exactly what we're building. But opening it to thousands of external vendors brings two things you didn't ask for because you had no reason to think about them, and that if we don't include them will cost us much more later. Let me explain them:

The first is being able to know when something breaks, instantly. Today, with our own teams, if a service goes down at night, we more or less find out. But when there are thousands of vendors depending on the platform to sell, a service down for two hours without us realizing means thousands of vendors who couldn't sell —and who will complain, publicly, and some of whom will leave for the competition—. We're including an alerting system that tells us in minutes, not hours. It costs something, yes; but it's much cheaper than a silent outage in high season.

The second is being able to trace every transaction. The day —and it will come— when a vendor claims 'I was overcharged' or the regulator investigates an operation suspected of money laundering, we'll have to show exactly what happened, when, and who did it. If we don't keep that trail from the start, that day we won't be able to reconstruct it, and that's a fine, a legal problem, or a vendor who sues us. Keeping the trail from now is cheap; trying to reconstruct it when it doesn't exist is impossible.

Neither of the two is a technical luxury: they're the two insurances that keep opening the platform from becoming a bigger problem than the one it solves. I can show you the cost of each one against the risk it covers, so you decide the level."

Why it works: (1) it validates the VP's request ("that's what we're building") instead of contradicting it; (2) it translates each implicit attribute into a catastrophe the VP understands (lost sales from a silent outage, fine/lawsuit from lack of a trail); (3) it frames the cost as insurance against a bigger risk, which is the business's language; (4) it offers to decide the level against the cost, respecting that the final decision of how much is the business's. It's discovering the implicit (this lesson) and selling it as prevention (lesson 6) in a single conversation.

Summary and next step

In this lesson you learned to see the requirements no one writes and everyone expects: the implicit attributes, the tacit contract of the domain. With the house that "no one asked not to flood" you saw that an architect who delivers only the wish list —bedrooms without drainage, without insulation, without smoke detectors— isn't an architect, and that the good professional includes the implicit because they know the craft, and explains it to justify the cost. You measured it by executing: the gap between the five attributes Mercado's goals named and the six the domain demands without anyone asking (data integrity, auditability, privacy, usability, recoverability, observability) —six expensive surprises waiting to explode—. You understood that the implicit comes from three sources (the business domain, real operation, what the user assumes), that an explicit attribute can hide an enormous implicit body (security goes beyond the payment data), and that discovering the implicit is half —the other is selling it as prevention of concrete catastrophes, in the business's language—.

Before moving on you should be able to: build a domain's tacit contract by asking what the system handles (money, data, third parties) and who operates it; find the gap between what's asked and what's expected; look inside an explicit attribute to find its implicit parts; and justify each implicit one by the catastrophe it prevents, without inflating it into paranoia.

What follows is the skill that has been peeking out in every lesson and now takes center stage: the conversation with the stakeholder. You now know how to translate the business to attributes (lesson 2), make them measurable (3), filter the ones that matter (4), and discover the implicit ones (5). All that is work on the architect's side. But nothing gets built without the permission —and the budget— of someone who doesn't speak your language. In lesson 6 you'll learn to speak the stakeholder's language: to translate a technical trade-off into its business consequence, in money. You'll execute the table that converts availability levels into minutes down per year and into lost sales —"more availability = more money", with numbers—, and you'll understand why that translation back to the business is the half of the craft that decides whether your architecture gets to exist.

Resources

• Len Bass, Paul Clements, Rick Kazman — Software Architecture in Practice — its treatment of quality attributes includes the ones rarely asked for explicitly (modifiability, testability, availability) and how to elicit them; the basis for understanding that the stakeholder's list is never complete.
• ISO/IEC 25010 — software product quality model — going through its eight characteristics and their sub-characteristics is a systematic way to discover implicit attributes: for each category the business didn't mention, ask yourself whether its domain demands it tacitly.
• Michael Nygard — Release It! — the whole book is about the implicit requirements of operating in production (stability, recoverability, things failing without dragging down the whole system) —exactly the attributes no one asks for until they explode—. The best reading for the tacit contract of operation.
• OWASP — Application Security Verification Standard — a catalog of the security requirements a system must meet even if no one asks for them; the perfect example of an enormous body of implicit attributes within "security".