The property sheet of an AI component

Overview

The module gave you, piece by piece, everything you need to know to place an AI component: its contract is probabilistic (L2), it lives behind a boundary and it proposes (L3), it drags in five properties at once (L4), it's a core inside a shell (L5), and its shell is sized by its tolerance (L6). This lesson joins all of that into a single reusable artifact: the property sheet of an AI component. It's a form with the same fields for any feature —placement, tolerance, latency and cost budget, eval gate, guardrail, fallback, deterministic shell, data loop—, and each field points to the module of the guide that works it in depth. Filling in this sheet is the act of architecting an AI feature, and it's what you'll do in the project (L8) and, expanded, in the whole guide's capstone (M8).

You're going to see, executed, the sheet for Mercado's semantic search: the ten fields filled in, each labeled with its module. And you're going to see why this sheet is, at the same time, the module's summary and the index of the rest of the guide —because modules 2 through 7 are, one by one, how to fill in each field well—.

Connection with the module. This is the consolidation lesson. It introduces no new idea; it gives the shape of an artifact to all the module's ideas, so you leave with something you can use tomorrow in your work. The sheet takes the placement and the tolerance (this module), and leaves as fields-to-be-completed the budget (M2), the eval (M3), the guardrail (M4), the fallback (M5), the shell in depth (M6), and the data loop (M7). Lesson 8 fills in a sheet end to end for a real feature; module 8 does the same but building each mechanism. The boundary with AI Engineering, once more: the sheet describes the architectural properties of the component —where it lives, what contains it—, never its internal construction (the prompt, the RAG, the fine-tuning), which is AI Eng's work that the sheet simply makes room for.

An analogy: the datasheet of an electrical component

An engineer designing a circuit doesn't "wire in a motor and that's it." Before placing any component, they consult its datasheet: the standardized document that states everything they need to know to place it well —operating voltage, maximum current, heat dissipation, tolerance, temperature range, what protections it needs around it—. The datasheet doesn't tell them how the motor was manufactured internally (that's the manufacturer's business); it tells them its integration properties: what it needs to work without burning out the rest of the circuit.

The powerful thing about the datasheet is that it's the same format for all components. A motor, a capacitor, and a microcontroller have datasheets with comparable fields, even though they're different things. That lets the engineer reason uniformly: "what's the voltage of this one?, what protection does it need?", without reinventing the analysis for each piece. The datasheet is what turns "putting in a component" from an improvisation into a procedure.

Here's the point: the property sheet is the datasheet of an AI component. It doesn't describe how the model was built internally (that's AI Engineering, the "manufacturer"); it describes its integration properties —where it lives, how much latency and cost the system tolerates, what validates it, what happens if it goes down, what contains it—. And it's the same format for any Mercado AI feature: the search, the agent, the recommendations, the generator. Just like the electrical engineer, filling in the datasheet is what turns "adding AI" from an improvisation into a procedure. This lesson gives you the datasheet; the whole guide teaches you to fill in each field well.

Worked example: the sheet for Mercado's semantic search

We're going to model the sheet as a data structure —a dataclass— and print it, with each field labeled with the module of the guide that develops it. We use semantic search, a tolerant feature, precisely to show that even a thin-shell feature has its complete datasheet: the fields all exist, even if some are filled in "lightly."

# Lesson 7: the property sheet of an AI component.
# Consolidation: EVERY AI component is described with the same fields,
# and each field points to the module of the guide that works it in depth.
from dataclasses import dataclass, asdict


@dataclass
class AIComponentSheet:
    name: str
    location: str          # where it lives in the system
    nd_tolerance: int      # 3 (none) .. 15 (a lot)
    latency_budget_ms: int # M2
    cost_budget_usd: float # M2
    eval_gate: str         # M3
    guardrail: str         # M4
    fallback: str          # M5
    deterministic_shell: str  # M6
    feedback_loop: str     # M7


# The sheet for Mercado's semantic search: a TOLERANT feature.
# (We don't build the RAG: that's AI Engineering. Only its properties.)
sheet = AIComponentSheet(
    name="semantic_search",
    location="behind search-service, after the classic keyword route",
    nd_tolerance=13,
    latency_budget_ms=400,
    cost_budget_usd=0.0008,
    eval_gate="recall@10 over 50 labeled queries; score drops -> blocks deploy",
    guardrail="filter results the user has no permission for; hide withdrawn products",
    fallback="if the model is slow/down -> classic keyword search",
    deterministic_shell="thin: re-ranks, never decides price or stock",
    feedback_loop="post-search clicks and purchases feed the eval-set",
)

MODULE_OF = {
    "location": "M1", "nd_tolerance": "M1",
    "latency_budget_ms": "M2", "cost_budget_usd": "M2",
    "eval_gate": "M3", "guardrail": "M4", "fallback": "M5",
    "deterministic_shell": "M6", "feedback_loop": "M7",
}

print(f"=== Property sheet: {sheet.name} ===")
for field, value in asdict(sheet).items():
    if field == "name":
        continue
    mod = MODULE_OF.get(field, "  ")
    print(f"  [{mod:>2}] {field:<20} {value}")

print()
print("Each [Mx] is the module that goes deep on that field. The sheet is the")
print("component's architectural contract: it's filled here (M1) and")
print("completed throughout the guide.")

What to expect. When you run the file, the output is exactly this:

=== Property sheet: semantic_search ===
  [M1] location             behind search-service, after the classic keyword route
  [M1] nd_tolerance         13
  [M2] latency_budget_ms    400
  [M2] cost_budget_usd      0.0008
  [M3] eval_gate            recall@10 over 50 labeled queries; score drops -> blocks deploy
  [M4] guardrail            filter results the user has no permission for; hide withdrawn products
  [M5] fallback             if the model is slow/down -> classic keyword search
  [M6] deterministic_shell  thin: re-ranks, never decides price or stock
  [M7] feedback_loop        post-search clicks and purchases feed the eval-set

Each [Mx] is the module that goes deep on that field. The sheet is the
component's architectural contract: it's filled here (M1) and
completed throughout the guide.

Read the sheet from top to bottom, because each line is an architectural decision this module taught you to see and the following ones will teach you to resolve well.

The first two fields —location and nd_tolerance— are from this module. The placement ("behind search-service, after the classic keyword route") says where the component lives and what surrounds it: semantic search doesn't replace classic search, it's placed behind it, which already hints at the fallback. The tolerance (13) summarizes lesson 6's analysis: a tolerant feature, thin-shelled. These two fields are what you know how to do when you finish M1.

The other fields are the map of the rest of the guide. The budget (400 ms, $0.0008 per call) is module 2: how much latency and cost the system can absorb. The eval gate (recall@10 over 50 queries, which blocks the deploy if it drops) is module 3: how you test something probabilistic. The guardrail (filter without permission, hide withdrawn) is module 4: what's validated at the boundary. The fallback (to classic search if the model goes down) is module 5: what happens when it fails. The deterministic shell ("thin: re-ranks, never decides price or stock") is module 6: the containment, here explicitly light because the feature is tolerant. And the data loop (clicks and purchases feed the eval-set) is module 7: how it improves with use.

Notice what the sheet doesn't have: there's no "prompt" field, nor "embedding model," nor "how the RAG is done." That's deliberate —it's the boundary with AI Engineering—. The sheet describes how the component integrates and is contained, not how it's built internally. The "motor manufacturer" (AI Eng) takes care of making the core work; the sheet takes care of placing it well in the circuit.

And the closing says it: the sheet is the architectural contract of the component. You start filling it here (M1, the first two fields) and complete it throughout the guide. When you finish the eight modules, you'll know how to fill in the ten lines for any AI feature a system wants to add. The whole guide fits in this datasheet.

Going deeper: the sheet as index, contract, and checklist

It's worth seeing the sheet's three uses, because each makes it valuable at a different moment of the work.

The sheet is the guide's index. Look at the module column: [M1] [M1] [M2] [M2] [M3] [M4] [M5] [M6] [M7]. It's no coincidence that nearly all of them appear: the sheet is the guide, seen as a single form. Learning AI-native architecture is learning to fill in each field well, and each module is a field. This gives you a mental map for the rest of the course: when you enter module 2, you'll know you're learning to fill in latency_budget_ms and cost_budget_usd; in module 4, guardrail; and so on. The sheet turns a list of topics into a structure with purpose.

Sheet field                Question it answers                       Module
─────────────────────────  ────────────────────────────────────────  ──────
location                   Where does it live and what surrounds it? M1
nd_tolerance               How much non-determinism does it take?    M1
latency_budget_ms          How long can it take?                     M2
cost_budget_usd            How much can it cost per call?            M2
eval_gate                  How do I test something probabilistic?    M3
guardrail                  What do I validate at the boundary?       M4
fallback                   What if the model fails?                  M5
deterministic_shell        What contains its actions?                M6
feedback_loop              How does it improve with use?             M7

The sheet is a contract between teams. When the AI Engineering team hands over a component (a semantic search engine, an agent), the sheet is the document that says how the platform team is going to integrate and contain it. It makes explicit what the shell guarantees, what the budget is, what happens if the core fails. It's the interface between "who builds the core" and "who places it in the system" —two different jobs, with the sheet as a clean boundary between them—. Without the sheet, that boundary blurs and the two teams end up stepping on each other (AI Eng getting into how it's integrated, platform getting into how it's prompted).

The sheet is a completeness checklist. An empty field in the sheet is an unresolved front —exactly the ones lesson 4 called "the iceberg"—. If you're about to launch a feature and its sheet has fallback blank, you know it has no plan for when the model goes down; if it has guardrail empty on a feature that publishes content, you know its output isn't validated. The sheet turns "are we ready for production?" from a feeling into a concrete review: are the ten fields filled in, and filled in to the level of the feature's tolerance? A tolerant feature can have "light" fields (search has a "thin" shell), but none empty —tolerant isn't the same as careless—.

One sheet per feature, not one per system. Each AI component has its own sheet, because each has its own tolerance and risk profile (lesson 6). Mercado with its four features will have four sheets: search's (thin), the refunds agent's (all fields "thick"), recommendations' and the generator's (intermediate, with different emphasis). Comparing the four sheets side by side is, at a glance, the map of where the system's greatest AI risk surface is —and therefore where to invest more containment engineering—.

Common mistakes

Leaving fields blank and calling the feature "ready." What happens: the team fills in location, eval_gate, and little more, leaves fallback, guardrail, and deterministic_shell empty, and declares the feature ready for production. The empty fields are exactly the iceberg fronts that will explode. Why it happens: empty fields don't hurt until the model goes down, or hallucinates, or someone injects. How to spot it: your sheet has unfilled fields and there's no explicit justification for why that feature doesn't need them. How to fix it: require that all ten fields have something —even if it's "doesn't apply because it doesn't touch state" with the reason—. A blank field is an undecided front; a field with "doesn't apply and this is why" is a decision made. The difference between the two is the difference between a designed feature and an improvised one.

Putting the core's construction into the sheet. What happens: someone adds to the sheet fields like "prompt," "embedding model," "RAG chunking strategy," and the sheet becomes the documentation of how the model was built. Why it happens: describing the component is confused with describing its interior. How to spot it: your sheet has fields that answer "how does the core work internally?" instead of "how is it integrated and contained?". How to fix it: keep the sheet at the integration layer —the datasheet's properties, not the manufacturing blueprints—. The prompt and the RAG are AI Engineering's business and live in their documentation; the architectural sheet makes room for that core (treats it as a box that proposes) without absorbing its construction. If the sheet starts talking about a prompt's tokens, you crossed the boundary.

A single sheet for the whole system. What happens: the team makes one "Mercado AI" sheet that averages the four features. The result is useless: it mixes search's tolerance 13 with the agent's tolerance 3, and ends up with an "average" shell that over-designs search and under-designs the agent. Why it happens: a single sheet seems simpler to maintain. How to spot it: you have a sheet with fields that say "depends on the feature" or averaged values. How to fix it: one sheet per AI component. The tolerance and the risk profile are per feature (lesson 6), so the sheet is too. Four features, four sheets. Comparing them is valuable information; merging them destroys it.

Exercises

Exercise 1 — Fill in the refunds agent's sheet. The support agent that executes refunds is Mercado's most intolerant feature (tolerance 3, all mechanisms mandatory). Write its property sheet —the ten fields—, and contrast each field with semantic search's to show why its shell is "thick" where search's is "thin."

name                 support_agent_refunds
location             in support-service, between the customer's ticket and the payments API
nd_tolerance         3   (vs search's 13: intolerant, touches money)
latency_budget_ms    5000  (more slack: the customer waits for a resolution, not an instant search)
cost_budget_usd      0.02  (higher: it reasons over the ticket; justified by the value of resolving)
eval_gate            % of proposals within policy over 100 labeled tickets; drops -> blocks deploy
guardrail            validate input (prompt injection in the ticket) AND output (schema {order_id, amount})
fallback             if the model goes down -> queue the ticket to a human agent (never auto-approve)
deterministic_shell  THICK: validates the proposal against the refund policy before touching money
feedback_loop        human approvals/rejections and corrections feed the eval-set

Exercise 2 — The blank field. You review a colleague's new feature sheet and see that fallback is empty. The feature is a FAQ chatbot on the help page. Formulate the questions you'd ask to fill in that field, and explain why an empty fallback is a problem even though the feature is "just a FAQ chatbot."

Exercise 3 — The sheet as a boundary between teams. The AI Engineering team hands Mercado a semantic search engine "ready to integrate." The platform team is going to place it. Explain which parts of the sheet are each team's responsibility, and why the sheet makes the collaboration between the two cleaner than if it didn't exist.

Summary and next step

In this lesson you consolidated the whole module into a reusable artifact: the property sheet of an AI component. It's the datasheet of an AI feature —ten fields: placement, tolerance, latency and cost budget, eval, guardrail, fallback, deterministic shell, data loop— with each field pointing to the module that works it in depth. You saw it executed for Mercado's semantic search, and you saw its three uses: it's the index of the guide (each field is a module), a contract between the team that builds the core and the one that places it, and a completeness checklist where a blank field is an unresolved iceberg front. And you saw its boundary: the sheet describes how the component integrates and is contained, never how it's built internally —that's AI Engineering—.

Before moving on you should be able to: name the ten fields of the sheet and the module of each; fill in a sheet for a given feature; explain why a blank field is a problem even if the feature is tolerant; and why there's one sheet per feature and not one per system.

Lesson 8 is the mini-project: you're going to fill in a sheet end to end for a real Mercado feature —the "describe your product" generator— and execute the properties this module taught you. You'll classify its tolerance, separate its core from its shell, demonstrate the probabilistic contract (the exact assert breaks, the property one passes), watch the shell block a forbidden claim, and emit its property sheet with a decision brief. Everything from the module, integrated into a single executed deliverable —and without building the generator, because that's AI Engineering—.

Resources

• Martin Fowler and Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. The catalog of patterns maps almost one-to-one with the sheet's fields (eval, guardrail, RAG as a context fallback). It's the "catalog" version of what the sheet organizes into one form. In English.
• Michael Nygard, "Documenting Architecture Decisions" (2011) — cognitect.com/blog/2011/11/15/documenting-architecture-decisions. The property sheet is a relative of the ADR: a standardized artifact that captures an architectural decision. The project's decision brief leans on this idea. In English.
• Anthropic, "Building Effective Agents" (2024) — anthropic.com/engineering/building-effective-agents. Useful for filling in the containment fields (guardrail, fallback, shell) of an agent's sheet well. In English.
• Chip Huyen, AI Engineering (O'Reilly, 2024). Its tour through the components of a system with foundation models is, in practice, a tour through the sheet's fields from the core-construction side —the complement to the integration side this guide teaches—. In English.