{
  "id": "dd-14-exam",
  "title": "DD-14 Mastra — Observability Primitives (Native Pattern + Read/Write Memory)",
  "deep_dive": "dd-14-mastra",
  "course": "master-course",
  "duration_minutes": 30,
  "pass_threshold": 0.70,
  "question_count": 15,
  "bloom_distribution": {"recall": 3, "application": 6, "analysis": 6},
  "questions": [
    {
      "id": "q01",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "What are Mastra's two distinctive contributions?",
      "options": [
        "A 7-provider sandbox abstraction and a governance layer.",
        "Observability as a first-class primitive (native event emission, not a wrapper) and explicit read/write memory tier separation (separate interfaces for read and write).",
        "A multi-agent crew abstraction and a shared memory store.",
        "An auto-compaction four-part mechanism and tiered memory stores."
      ],
      "answer_index": 1,
      "rationale": "Mastra's two distinctive contributions: (1) observability as a first-class primitive — components emit structured events natively as part of their interface, not via a wrapper — the Module 10 reference; (2) explicit read/write memory tier separation — readMemory and writeMemory are separate interfaces — the Module 4.3 reference. The 7-provider sandbox is DD-11 (Agents SDK); the crew abstraction is DD-12 (CrewAI); the four-part compaction is DD-13 (OpenHarness)."
    },
    {
      "id": "q02",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "What is the distinction between the wrapper pattern and the native pattern for observability?",
      "options": [
        "The wrapper pattern uses fewer dependencies; the native pattern uses more.",
        "Wrapper: withObservability(agent, { tracer }) — observability applied externally, sees only boundary crossings, can drift out of sync. Native (Mastra): component.run(input) → { result, events[] } — the component owns its event emission, internal decisions are visible, the contract cannot drift.",
        "The wrapper pattern is faster; the native pattern is slower.",
        "The wrapper pattern is for production; the native pattern is for research."
      ],
      "answer_index": 1,
      "rationale": "The wrapper pattern (most SDKs, Module 1.4) applies observability externally via withObservability(agent, { tracer }). The component knows nothing about tracing; the wrapper intercepts calls and records spans. Its weakness: it sees only boundary crossings, and it can drift out of sync with the component's behavior. The native pattern (Mastra) makes observability part of the component contract: component.run(input) → { result, events[] }. The component owns its event emission; internal decisions are visible; the contract cannot drift because emission is part of the interface."
    },
    {
      "id": "q03",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "Name the three properties that native event emission buys you.",
      "options": [
        "Lower latency, smaller bundle size, fewer dependencies.",
        "Internal decisions visible (why a tool was chosen, what was pruned), the contract cannot drift (emission tracks the component or fails to compile), and every consumer gets the same stream (no 'telemetry says X but logs say Y' gap).",
        "Better type safety, faster compilation, smaller memory footprint.",
        "More integrations, larger community, better documentation."
      ],
      "answer_index": 1,
      "rationale": "The three properties: (1) Internal decisions are visible — a wrapper sees tool calls; a native emitter sees why the tool was chosen, what alternatives were rejected, what was pruned. (2) The contract cannot drift — emission is part of the interface, so events track the component as it evolves or fail to compile. (3) Every consumer gets the same stream — logger, dashboard, alerting, replay all read the same events. The cost: you must build native to get the benefit."
    },
    {
      "id": "q04",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are debugging a long agent run where the agent picked an unexpected tool at step 7. Your SDK uses the wrapper pattern. What can you see, and what is invisible?",
      "options": [
        "You can see everything — the wrapper captures all internal decisions.",
        "You can see the tool call at step 7 (a boundary crossing). You CANNOT see why the tool was chosen, what alternatives were rejected, or what the component pruned from context — those are internal decisions the wrapper does not see. To debug the choice, you would need a native emitter.",
        "You can see nothing — the wrapper does not capture tool calls.",
        "You can see the full reasoning trace — the wrapper intercepts every internal decision."
      ],
      "answer_index": 1,
      "rationale": "The wrapper pattern sees boundary crossings (tool calls, API calls) but not internal decisions. Why the tool was chosen, what alternatives were rejected, and what was pruned from context are internal to the component — invisible to a wrapper that only intercepts calls. This is the difference between a span tree (wrapper) and a reasoning trace (native). A native emitter like Mastra exposes the internal decisions; a wrapper does not."
    },
    {
      "id": "q05",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "Your team has an off-the-shelf LLM wrapper component and wants to slot it into Mastra to get Mastra's native observability. Will this work, and what is the load-bearing reason?",
      "options": [
        "Yes — Mastra's observability applies to any component automatically.",
        "No — the native pattern only pays off when components are native. The off-the-shelf wrapper does not emit Mastra's events; you inherit its observability gap. The event stream shows a hole wherever the non-native component runs. Build a native adapter or use a wrapper-based SDK.",
        "Yes — Mastra will wrap your component in its tracer.",
        "Yes, but only if you enable TypeScript strict mode."
      ],
      "answer_index": 1,
      "rationale": "The cost of the native pattern: it only pays off when components are native. If you bring your own components (an off-the-shelf LLM wrapper, a custom tool) and slot them into Mastra, those components do not emit Mastra's events — you inherit their observability gap. The event stream shows a hole wherever your non-native component runs. The cure: build your components against Mastra's primitives, or wrap them in a native adapter that emits the events they do not. If the team is unwilling to build native, the native pattern does not apply."
    },
    {
      "id": "q06",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You want to defend against memory poisoning — an agent should be able to read prior context but must not be able to write poisoned entries. Which architecture makes this defense structural, and how?",
      "options": [
        "A conflated memory store with a policy that checks each write — the policy enforces 'do not write poisoned content.'",
        "Mastra's read/write split — give the agent the readMemory interface and withhold the writeMemory interface. The agent has no handle to call writeMemory, so poisoning is not possible. The defense is in the type system, not a policy layer.",
        "A shared memory store where every agent can write — write-gating is enforced by convention.",
        "A memory store with logging — poisoned writes are detected after the fact."
      ],
      "answer_index": 1,
      "rationale": "Mastra's explicit read/write split makes the defense structural. The memory-poisoning defense is fundamentally a write-path control. If reads and writes share a handle (a conflated store), restricting writes means intercepting calls and checking intent — a policy layer bolted onto a unified interface, which can be bypassed or misconfigured. If reads and writes are separate interfaces (Mastra), restricting writes is an interface-level decision: give the read interface, withhold the write interface. The agent has no handle to call, so misuse is not possible. The defense is in the type system."
    },
    {
      "id": "q07",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are comparing Mastra (DD-14) and CrewAI (DD-12) for a multi-agent system that needs write-gating to prevent memory poisoning. Which should you pick, and why?",
      "options": [
        "CrewAI — its crew-scoped shared memory makes write-gating easier.",
        "Mastra — its explicit read/write split makes write-gating an interface-level decision (withhold the write interface). CrewAI's crew-scoped shared memory means every agent can write what every other agent reads — write-gating is unavailable by default because there is no separate write interface to withhold.",
        "Either — both provide equivalent write-gating.",
        "Neither — write-gating must be implemented from scratch in both."
      ],
      "answer_index": 1,
      "rationale": "Mastra's explicit read/write split makes write-gating structural — the write interface can be withheld at the type level. CrewAI's crew-scoped shared memory means every agent shares one store and can write what every other agent later reads. There is no separate write interface to withhold, so the write-gating defense is unavailable by default — you would need to bolt on a policy layer, which is advisory rather than structural. For memory-poisoning defense, Mastra is the cleaner abstraction."
    },
    {
      "id": "q08",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are deploying an agent that needs TypeScript DX, observability for a SIEM layer, AND bash sandboxing. Which harness combination do you pick?",
      "options": [
        "Mastra alone — it covers all three.",
        "Mastra for TypeScript DX and observability (native event emission for the SIEM), paired with the Agents SDK (DD-11) for the 7-provider sandbox abstraction. Mastra gives you the observability and memory safety; the Agents SDK gives you the containment. Neither harness alone covers all three.",
        "The Agents SDK alone — it has sandboxing and TypeScript DX.",
        "NemoClaw alone — it has governance and observability."
      ],
      "answer_index": 1,
      "rationale": "Mastra scores 5/5 on Module 10 (Observability) and 5/5 on Module 4.3 (Write-gating) but 1/5 on Module 5 (Sandbox — none). The Agents SDK (DD-11) provides the 7-provider sandbox abstraction Mastra lacks. The correct production architecture is composition: Mastra for observability and memory safety, the Agents SDK for sandboxing. This is the 'pair Mastra with a harness that has the security modules' pattern from the architect's verdict. Neither harness alone covers all three requirements."
    },
    {
      "id": "q09",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "Your team adopted Mastra for its read/write split and assumes they are now secure against memory poisoning. What is the anti-pattern, and how do you correct it?",
      "options": [
        "There is no anti-pattern — the read/write split is a complete security model.",
        "The anti-pattern is treating the read/write split as sufficient security. The split makes memory-poisoning defense structural at the MEMORY layer only. It says nothing about the sandbox layer (Module 5: 1/5) or verification layer (Module 9: 1/5). An agent without the write interface can still call bash without containment. Correct: read the split as one structural defense, not a security model. Pair with a sandboxed harness.",
        "The anti-pattern is using TypeScript — switch to Python.",
        "The anti-pattern is using native observability — switch to the wrapper pattern."
      ],
      "answer_index": 1,
      "rationale": "The read/write split makes memory-poisoning defense structural at the memory layer only. It says nothing about the sandbox layer (Module 5: 1/5 — no sandbox), the verification layer (Module 9: 1/5 — none), or the overall security model (Module 11: 2/5 — the split is an asset but there is no SECURITY model). An agent without the write-memory interface cannot poison memory, but it can still call bash without containment and ship data to an external endpoint. The cure: read the read/write split as one structural defense, not a security model. Pair Mastra with a harness that has the sandbox and verification modules implemented."
    },
    {
      "id": "q10",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Mastra (DD-14) and NemoClaw (DD-09) both make security-relevant decisions at the type level rather than the policy level. What is the shared structural principle, and why is it the strongest form of defense?",
      "options": [
        "Both use extensive logging to detect misuse after the fact.",
        "Both use policy layers that check intent before allowing operations.",
        "Both remove the handle entirely — NemoClaw places credentials outside the sandbox's reach (no handle to leak), Mastra withholds the write-memory interface (no handle to poison). The defense is architectural: there is nothing to bypass, misconfigure, or forget. This is interface-level defense, the strongest form.",
        "Both rely on runtime verification of every operation."
      ],
      "answer_index": 2,
      "rationale": "The shared structural principle is interface-level defense: the handle does not exist, so misuse cannot arise. NemoClaw places credentials outside the sandbox's reach — the sandboxed agent never has a handle to the credentials, so the question of leaking them cannot arise inside the sandbox. Mastra withholds the write-memory interface — the agent never has a handle to call writeMemory, so the question of poisoning memory cannot arise. Different layers (sandbox credentials vs memory writes), one principle: the strongest defense is to remove the handle, not to write a policy that says 'do not misuse it.' Advisory defenses can be bypassed, misconfigured, or forgotten; interface-level defenses cannot."
    },
    {
      "id": "q11",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Mastra and DD-21 (Tau) both treat events as the cross-layer contract. What is the difference in emphasis, and what does the convergence demonstrate?",
      "options": [
        "Mastra is for research; Tau is for production.",
        "Mastra makes native event emission the primitive for a production SDK; Tau makes the typed event union the observability layer for a teaching harness. Different emphasis (production primitive vs teaching layer), same conclusion (observability belongs in the component, not around it). The convergence is evidence the principle is load-bearing — two independent designs arrived at the same answer.",
        "Mastra uses a wrapper; Tau uses native emission.",
        "Mastra has fewer events; Tau has more."
      ],
      "answer_index": 1,
      "rationale": "The difference is emphasis: Tau makes the 14-member typed event union the observability layer for a teaching harness; Mastra makes native event emission the primitive for a production SDK. They converge on the same conclusion: observability belongs in the component, not around it. Events ARE the cross-layer contract. The convergence demonstrates that events-as-contract is a load-bearing principle — two independently designed harnesses (one academic, one production) arrived at the same architectural answer. Convergent design is evidence the principle is not incidental."
    },
    {
      "id": "q12",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Mastra scores 34/60. A colleague says 'Mastra is weaker than the Agents SDK (38/60).' How do you correct the comparison?",
      "options": [
        "You agree — 34 is less than 38, so Mastra is weaker.",
        "You correct the comparison: the scores measure different shapes. Mastra is the observability-and-memory shape (5/5 on Module 10, 5/5 on Module 4.3). The Agents SDK is the sandboxing-and-composition shape (5/5 on Module 5). The right question is not 'which is higher' but 'which shape fits your requirements.' For observability and memory safety, Mastra. For sandboxing and composition, the Agents SDK. Often you compose both.",
        "You argue the rubric is wrong and Mastra should be re-scored higher.",
        "You argue the Agents SDK is overrated and should be re-scored lower."
      ],
      "answer_index": 1,
      "rationale": "Comparing Mastra (34/60) and the Agents SDK (38/60) by the total score alone is the wrong frame. The scores measure different shapes. Mastra is the observability-and-memory shape — 5/5 on Module 10 (native event emission, best in roster) and 5/5 on Module 4.3 (interface-level write-gating, the reference). The Agents SDK is the sandboxing-and-composition shape — its strength is the 7-provider sandbox abstraction (Module 5). The right question is not 'which total is higher' but 'which shape fits your requirements.' For observability and memory safety, Mastra. For sandboxing and composition, the Agents SDK. In production, you often compose both."
    },
    {
      "id": "q13",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "OpenHarness (DD-13) scores 4/5 on Module 10; Mastra (DD-14) scores 5/5. What is the gap that keeps OpenHarness at 4/5, and what does the contrast teach about the observability axis?",
      "options": [
        "OpenHarness has no observability; Mastra does.",
        "OpenHarness emits human-readable logs; Mastra emits machine-readable structured events. The gap is that human-readable logs are inspectable by a person but not analyzable at scale (no structured query, no SIEM integration, no replay). The contrast defines the observability axis: research reproducibility (OpenHarness, human-readable) vs production operability (Mastra, machine-readable). Same goal, different objective functions.",
        "OpenHarness uses a wrapper; Mastra uses native emission — but both are production-grade.",
        "OpenHarness has more events; Mastra has fewer."
      ],
      "answer_index": 1,
      "rationale": "OpenHarness's inspectability is currently human-readable — a person can read the decision log, but it is not analyzable at scale (no structured query, no automated alerting, no SIEM pipeline integration, no replay against a benchmark). Mastra emits machine-readable structured events that are analyzable at scale. The gap that keeps OpenHarness at 4/5 on Module 10 while Mastra is 5/5 is exactly the machine-readable-logs gap — the third thing OpenHarness would need to fix if misused as production. The contrast defines the observability axis: research reproducibility (OpenHarness) vs production operability (Mastra). Same goal — see what the agent did — different objective functions."
    },
    {
      "id": "q14",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Why does Module 4.3 (write-gating) point at Mastra as the reference, and what is the architectural property that makes Mastra's write-gating stronger than a policy-based approach?",
      "options": [
        "Mastra has the most comprehensive write-gating policy rules.",
        "Mastra's write-gating is stronger because it is interface-level, not policy-level. Read and write are separate interfaces; witholding the write interface means the agent has no handle to call writeMemory. The defense is in the type system — there is nothing to bypass, misconfigure, or forget. A policy-based approach checks intent on a unified handle, which is advisory and can be bypassed.",
        "Mastra's write-gating is stronger because it logs every write.",
        "Mastra's write-gating is stronger because it runs in TypeScript."
      ],
      "answer_index": 1,
      "rationale": "Module 4.3 points at Mastra because Mastra makes write-gating interface-level rather than policy-level. The memory-poisoning defense is fundamentally a write-path control. In a conflated store, restricting writes means intercepting calls and checking intent on a unified handle — a policy layer bolted onto the interface. This is advisory: it can be bypassed, misconfigured, or forgotten. In Mastra, reads and writes are separate interfaces; withholding the write interface means the agent has no handle to call. The defense is in the type system — architectural, not advisory. This is the same structural principle as NemoClaw's credentials-outside-the-sandbox: remove the handle, do not write a policy."
    },
    {
      "id": "q15",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "The course draws a structural parallel between Mastra's read/write split and NemoClaw's credential isolation. Which earlier deep-dive drew an analogous parallel between two pole pairs defining a load-bearing axis, and what was the axis?",
      "options": [
        "DD-08 (Hermes) drew the parallel between session-state and tool-result poisoning — the compounding-poisoning axis.",
        "DD-12 (CrewAI) drew the parallel between NemoClaw-vs-Tau (governance axis, C2B) and CrewAI-vs-LangGraph (coordination axis, C4 E09). Both are pole pairs that define load-bearing axes. The methodological principle is the same: identify the pole pair, name the axis, and the axis becomes load-bearing for a later module.",
        "DD-11 (Agents SDK) drew the parallel between handoffs and agents-as-tools — the composition axis.",
        "DD-13 (OpenHarness) drew the parallel between inspectability and observability — the legibility axis."
      ],
      "answer_index": 1,
      "rationale": "DD-12 (CrewAI) drew the analogous structural parallel: NemoClaw-vs-Tau defines the governance axis (load-bearing for Course 2B), and CrewAI-vs-LangGraph defines the coordination axis (load-bearing for Course 4 E09). Both are pole pairs that define load-bearing axes. The methodological principle is the same one Mastra and NemoClaw share: identify the pole pair (or the shared structural property), name the axis (or the principle), and the axis becomes load-bearing for a later module. In Mastra's case, the shared structural property is interface-level defense; the pole pair is NemoClaw (sandbox layer) and Mastra (memory layer), and the principle is 'remove the handle, do not write a policy.' The course keeps returning to this structural move because it is the strongest form of defense."
    }
  ]
}