Table of Contents

Labs

Labs are the practice and reasoning layer of AsiBackbone Learning.

Tutorials explain architectural boundaries.

Executable samples demonstrate them.

Labs ask you to work with those boundaries yourself.

The intended progression is:

Tutorial
   ↓
Executable Sample
   ↓
Hands-On Lab
   ↓
Alternative Approach
   ↓
Working Repository

Architectural Acceptance Criteria

A lab is not complete merely because the modified program runs.

The stronger question is:

Does the result preserve and demonstrate the architectural boundary the exercise was designed to teach?

Unless a lab states more specific criteria, use this lightweight self-check:

  • [ ] Required boundary demonstrated — you can point to the responsibility or trust boundary the lab is teaching and show where it is enforced.
  • [ ] Prohibited path absent — the failure or bypass path the lab is intended to prevent cannot silently reach protected execution or broader authority.
  • [ ] Decision evidence preserved — when the exercise involves decisions, acknowledgment, capabilities, or lifecycle state, enough evidence remains to explain what happened.
  • [ ] Relevant failure path observable — at least one important denied, stale, invalid, unavailable, replayed, or otherwise unsafe path can be observed rather than assumed.
  • [ ] Architectural invariant verified — a focused test, deterministic sample result, or equivalent observation demonstrates the property being taught.
  • [ ] Tradeoff or alternative explained — you can explain why your design is appropriate for the exercise and name a credible simpler or different approach when one exists.

Individual labs may strengthen, remove, or specialize these items when the subject requires different evidence.

The criteria intentionally evaluate outcomes rather than one prescribed implementation. Two solutions can look different in code and still succeed if both preserve the same architectural invariant.

Automated tests are useful evidence, but they are not the entire learning result. A test can pass while an important responsibility has moved to the wrong component, a bypass path remains reachable, or the learner cannot explain why the boundary matters.

Current Status

The lab navigation foundation is established, with four beginner labs, eight intermediate labs, and six advanced labs now available.

Additional labs will appear in this section as the learning path expands into deeper architecture, security, and AI-governance topics.

The foundational labs pair all five governance tutorials with executable companion samples and ask learners to modify, challenge, extend, and threat-model the demonstrated boundaries. The governance lab path now also includes policy-version evidence, candidate-policy simulation, decision-pipeline refactoring, competing-policy-architecture selection, regional/tenant overlay design, synthesis-oriented flawed high-consequence workflow analysis, and an explicit critique of AI-owned proposal-plus-execution authority, while the ASP.NET Core diagnostic lab begins the next learning area by requiring learners to predict, observe, repair, and explain middleware-ordering behavior; the ADR lab extends that application-architecture path by requiring learners to make, record, and revisit a decision under changed constraints.

Available Labs

Decision Before Execution

Decision Before Execution

Difficulty: Beginner

Break the execution boundary deliberately, observe why correct decision values are insufficient when the host ignores them, repair the boundary, and add a new policy constraint without moving governance logic into the executor.

Related material:

Policy Context and Explicit Decision Outcomes

Policy Context and Explicit Decision Outcomes

Difficulty: Beginner

Collapse structured decisions back to a boolean to observe the information loss, extend the explicit policy context, add a stable reason-coded rule, and make rule precedence observable and testable.

Related material:

Identify and Remove a Hidden Execution Side Effect

Identify and Remove a Hidden Execution Side Effect

Difficulty: Beginner

Start from deliberately flawed policy code that quietly starts an external deployment while it is still "checking" the request, make the denied-side-effect invariant fail visibly, and refactor the workflow so evaluation is observational and execution occurs only after an explicit decision boundary.

Related material:

Identify Middleware Ordering Problems

Identify Middleware Ordering Problems

Difficulty: Beginner

Run the deliberately incorrect ASP.NET Core pipeline, predict and observe the failure boundary, encode the repaired behavior in a focused test, reorder a disposable copy of the sample, and explain the changed request/response behavior in terms of wrapping, reachability, and coverage rather than a memorized middleware list.

Related material:

Decision Receipts and Acknowledgment

Decision Receipts and Acknowledgment

Difficulty: Intermediate

Break the acknowledgment boundary deliberately, add another response-binding failure, expose replay as a state problem, preserve correlated evidence behind an in-memory store, and distinguish an allowed decision from a failed execution.

Related material:

Scoped Capability and Host-Owned Execution

Scoped Capability and Host-Owned Execution

Difficulty: Intermediate

Break expiration and resource-freshness checks deliberately, observe how stale authority can reach execution, restore narrow execution-boundary validation, and extend the sample with additional binding and replay exercises.

Related material:

Replay Protection and Bounded-Use Authority

Replay Protection and Bounded-Use Authority

Difficulty: Intermediate

Reproduce a deterministic check-then-act race, repair it with atomic TryConsume semantics, prove that exactly one concurrent final-use consumer reaches protected execution, and reason about evidence, cancellation, durable state, idempotency, and the failure window between consumption and execution.

Related material:

Policy-Version Evidence in Governance Decisions

Policy-Version Evidence in Governance Decisions

Difficulty: Intermediate

Preserve the policy identity that produced a decision, detect policy drift across acknowledgment, capability issuance, and execution, and distinguish useful provenance from perfect replay or cryptographic proof.

Related material:

Policy Simulation and Change-Impact Analysis

Policy Simulation and Change-Impact Analysis

Difficulty: Intermediate

Replay identical deterministic contexts against baseline and candidate policy versions, compare outcome, reason-code, and contributor changes, expose expected and surprising change impact, add tenant and boundary cases, and prove that simulation never invokes protected execution.

Related material:

Build a Governed API Operation

Build a Governed API Operation

Difficulty: Intermediate

Extend an authorized ASP.NET Core account-disable endpoint into a governed operation with explicit intent, authoritative context, structured outcomes, acknowledgment, scoped authority, host-owned execution, decision receipt, and integration tests that prove blocked paths never invoke the underlying account service.

Related material:

Refactor Scattered Governance Checks into an Explicit Decision Pipeline

Refactor Scattered Governance Checks into an Explicit Decision Pipeline

Difficulty: Intermediate

Start from a deliberately flawed account.disable service where role checks, resource-dependent policy, mutation, notification, exception-driven escalation, acknowledgment, and event publication are interleaved. Diagnose the real side-effect boundary, refactor toward explicit context → decision → continuation → execution → evidence phases, and prove every blocked outcome leaves the protected executor at zero calls.

Related material:

Write and Revisit an Architecture Decision Record

Write and Revisit an Architecture Decision Record

Difficulty: Intermediate

Evaluate a structured-logging architecture under competing constraints, compare credible alternatives, write a concise ADR with explicit consequences and review conditions, then revisit the decision after the telemetry platform changes and decide whether the record should be retained, deprecated, superseded, or left unchanged while only the implementation evolves.

Related material:

Governed AI Tool Gateway

Governed AI Tool Gateway

Difficulty: Advanced

Compose the foundational patterns into one AI-assisted execution boundary, deliberately weaken proposal, context, acknowledgment, capability, replay, prompt, credential, and failure-mode controls, then threat-model the complete gateway.

Related material:

Safe Degraded Mode and Fail-Safe Governance

Safe Degraded Mode and Fail-Safe Governance

Difficulty: Advanced

Classify which trust or operational property is unavailable, compare low-consequence and consequential operations, design explicit deny/defer/escalate or bounded degraded behavior, and prove that policy, replay, verification, acknowledgment, evidence, and executor failures do not silently manufacture execution authority.

Related material:

Compare Competing Policy Architectures

Compare Competing Policy Architectures

Difficulty: Advanced

Choose among embedded rules, ASP.NET Core authorization, external policy evaluation, distributed enforcement, and richer governed-decision lifecycles across realistic scenarios. Defend each choice from explicit lifecycle, trust-boundary, availability, provenance, and operational constraints, then explain why a rejected alternative may be better under different requirements.

Related material:

Design a Regional and Tenant Policy Layer

Design a Regional and Tenant Policy Layer

Difficulty: Advanced

Design a conventional enterprise data-export overlay spanning global, regional, tenant, application, and operation-specific authorities. Define explicit precedence and override rules, preserve every contributing policy identity/version, handle conflicts and missing policy sources, detect region and tenant drift, require fresh authority before execution, and prove that evaluator registration order cannot silently determine governance authority.

Related material:

Analyze a Deliberately Flawed High-Consequence Workflow

Analyze a Deliberately Flawed High-Consequence Workflow

Difficulty: Advanced

Inspect a plausible but intentionally unsafe account.disable workflow without being given every defect up front. Trace caller-controlled facts, AI influence, policy, acknowledgment, cached approval, standing credentials, retry bypasses, replay, drift, dependency failure, and evidence paths; classify which findings can produce unauthorized or stale execution; then redesign the system around explicit current authority and host-owned execution invariants.

Related material:

Critique AI-Owned Proposal and Execution Authority

Critique AI-Owned Proposal and Execution Authority

Difficulty: Advanced

Critique a deliberately weak autonomous-operations agent that selects consequential tools, accepts policy facts from the prompt, self-approves, receives broad credentials, executes directly, retries autonomously, and records only a final explanation. Separate proposal autonomy from execution authority, restore host-owned registry/context/policy/credential/execution boundaries, and decide which controls can be omitted for lower-consequence or sandboxed scenarios.

Related material:

Start with the Tutorials

The foundational tutorial sequence establishes the concepts that the initial labs will build upon:

Browse Foundational Tutorials

Topics include:

  • Decision before execution
  • Explicit policy context and decision outcomes
  • Acknowledgment and decision receipt
  • Scoped capability and host-owned execution
  • Governed AI tool gateways

Study the Executable Samples

The executable sample area provides small runnable demonstrations corresponding to the tutorial concepts.

Browse Executable Samples

Samples demonstrate known behavior.

Labs will increasingly ask learners to modify, repair, critique, or extend that behavior.

Inspect the Working Repositories

After working through a teaching example or lab, compare the smaller architecture with fuller implementations.

AsiBackbone

AsiBackbone/AsiBackbone

A .NET governance and policy-control framework providing fuller implementations of policy evaluation, structured decisions, acknowledgment workflows, decision receipt, scoped capability, and host-owned execution.

NetCoreApplicationTemplate

AsiBackbone/NetCoreApplicationTemplate

An ASP.NET Core reference architecture demonstrating secure defaults, middleware organization, structured logging, rate limiting, authentication-ready design, data-access patterns, and operational application structure.

Learning Principle

The objective of a lab is not simply to reproduce a tutorial.

A useful lab should require you to make a decision, identify a failure mode, improve an architecture, or explain why one implementation is preferable under a particular set of constraints.

Read it. Run it. Question it. Improve it.

Edit this page