Find Your Path

AsiBackbone Learning can be used as a sequential course, but you do not need to read it that way.

If you already know the problem you are trying to solve, start with the shortest route that makes the relevant boundary visible. Stop when the simpler design preserves the behavior, evidence, and control you need; go deeper only when it does not.

Use the smallest architecture that preserves the boundaries you actually need.

Choose Your Problem

If you want to...	Start here
See governed execution work before reading the architecture	See the core boundary run quickly
Decide whether ASP.NET Core authorization is already enough	Evaluate ASP.NET Core authorization first
Govern a consequential administrative operation	Build an explicit governed operation
Govern AI-proposed tool execution	Keep model output as proposal, not authority
Reason about trust boundaries and operational security	Start from trust and least privilege
Preserve and revisit architecture decisions	Use ADRs to preserve reasoning

This page is a routing layer. It links to canonical material instead of restating the tutorials, samples, or labs.

How to Use a Path

Each route follows the same decision pattern:

Problem
   ↓
Start with the smallest relevant pattern
   ↓
Read only the supporting material you need
   ↓
Run or modify the executable example
   ↓
Stop if the simpler design is enough
   ↓
Go deeper only when the boundary requires it

The goal is not to maximize framework adoption. The goal is to make the architectural boundary visible enough that you can decide whether the additional lifecycle is justified.

I Want to See the Core Boundary Run Quickly

Problem: You want to see governed execution behave before reading the deeper architecture.

Start: Run the repository Quick Start. It demonstrates the foundational invariant that blocked decisions do not reach the executor.

Understand the boundary: Read Decision Before Execution.

Run and modify it: Use the Decision Before Execution sample and tests, then complete the Decision Before Execution lab.

Stop here when: The operation is ordinary application behavior with no meaningful decision boundary, acknowledgment requirement, scoped authority, or audit obligation. When a Simple Application Service Is Enough is the comparison point.

Go deeper when: Later policy, acknowledgment, capability, or AI boundaries matter. Continue through the foundational learning path.

I Already Use ASP.NET Core Authorization and Want to Know If That Is Enough

Problem: You already have framework-native authentication and authorization and do not want to introduce a broader governance model without a real need.

Start: When ASP.NET Core Authorization Is Enough.

Compare the simpler option: Read When a Simple Application Service Is Enough. These two pages deliberately put simpler application architecture before a larger governed-execution pipeline.

Continue only if needed: Read Decision Before Execution when the operation must become an explicit decision before a consequential side effect can occur.

Run and modify it: If the broader boundary is justified, use the Decision Before Execution sample and tests and the Decision Before Execution lab.

Stop here when: The question is only whether an authenticated principal may access an endpoint or resource, or when one application service can clearly own validation and execution.

Go deeper when: The problem grows beyond authorization into explicit outcomes, acknowledgment, capability, provenance, or policy composition. Use Architecture and Governance.

I Need to Govern a Consequential Administrative Operation

Problem: An administrative or operational action may require explicit policy context, non-boolean outcomes, acknowledgment, narrow execution authority, and evidence of what happened.

Start: Policy Context and Explicit Decision Outcomes.

Build the lifecycle: Continue with Decision Receipts and Acknowledgment, then Scoped Capability and Host-Owned Execution.

Administrative intent
      ↓
Policy context and explicit decision
      ↓
Acknowledgment when required
      ↓
Scoped capability
      ↓
Host-owned execution
      ↓
Decision receipt

See the composition: Governed Administrative Operation follows one fictional account.disable request through standing authorization, authoritative context, policy evaluation, acknowledgment or escalation, scoped authority, executor invocation, and correlated evidence.

Run and modify it: Use the related executable sample guide, then complete Build a Governed API Operation.

Stop here when: Ordinary ASP.NET Core authorization plus a clear application service already answers the access and execution questions. Compare When ASP.NET Core Authorization Is Enough and When a Simple Application Service Is Enough before adding governance machinery.

Go deeper when: You need policy composition, escalation, provenance, risk-based decisions, or stronger testing strategies. Browse Governance. For a fuller working implementation, inspect AsiBackbone/AsiBackbone.

I Need to Govern AI-Proposed Tool Execution

Problem: A model can propose a tool call or operation, but the host must retain authority over validation, policy, credentials, and real-world execution.

Start: Governed AI Tool Gateway.

Strengthen the proposal boundary: Add Typed AI-Proposed Intent and Schema-Validation Boundaries, then Deterministic and Probabilistic Inputs in Policy Evaluation when model-derived or risk-derived signals influence a decision.

Model proposal
      ↓
Typed and schema-valid intent
      ↓
Policy evaluation
      ↓
Explicit decision
      ↓
Host-owned tool execution

Run and modify it: Use the Governed AI Tool Gateway sample and tests, then complete the Governed AI Tool Gateway lab.

Stop here when: The model produces suggestions or data that never cross an execution boundary. Ordinary input validation and an application-owned service may be sufficient; do not build an execution gateway for a workflow that does not execute tools.

Go deeper when: You need broader AI governance or policy composition. Use AI Integration and Governance. If multiple autonomous participants begin proposing work to one another, continue to Governed Agent-to-Agent Requests and Multi-Agent Execution Boundaries.

I Need to Reason About Trust Boundaries and Operational Security

Problem: You need to decide where trust changes, where authority should narrow, what secrets may cross a boundary, what may be logged, and which threats the architecture must make visible.

Start: Trust Boundaries and Least Privilege.

Strengthen the trust model: Continue with Secret Handling Across Trust Boundaries, Secure Logging Across Trust Boundaries, and Threat Modeling as Architecture Reasoning.

Run and modify it: The Replay Protection and Bounded Use sample and lab make one concrete authority boundary executable by showing why issued authority still needs bounded, replay-resistant use.

Stop here when: Framework and platform security controls already preserve the boundary. Do not replace established authentication, authorization, secret stores, transport security, or logging controls with custom infrastructure merely to match a diagram.

Go deeper when: You need signing, verification, key custody, supply-chain integrity, replay protection, or related trust-architecture material. Browse Security.

I Need to Preserve and Revisit Architecture Decisions

Problem: The code shows what the system does, but future maintainers also need to recover why a consequential architectural choice was made, what alternatives existed, and what evidence should trigger review.

Start: Architecture Decision Records Preserve Architectural Reasoning.

Build the lifecycle: Continue with Architecture Decision Record Lifecycle, Review, Deprecation, and Supersession, then study Working Repository ADR Case Study: NetCoreApplicationTemplate.

Run and modify it: Complete Write and Revisit an Architecture Decision Record. The lab requires you to record a decision, preserve alternatives and consequences, then revisit it after the scenario changes.

Stop here when: The choice is a local implementation detail, routine refactor, or behavior whose reasoning is already obvious from the code. A code comment, pull-request explanation, or implementation guide is often a better fit than an ADR.

Go deeper when: You want more ASP.NET Core architecture material or a working repository specimen. Browse ASP.NET Core and inspect the NetCoreApplicationTemplate ADRs.

If None of These Paths Match

Use the subject-area landing pages instead of forcing your problem into a path that does not fit:

The path chooser is intentionally incomplete. It should remain a compact map of common reader goals rather than another table of contents.