Table of Contents

Getting Started

Welcome to AsiBackbone Learning.

This repository teaches governance and controlled-execution architecture through small explanations, runnable examples, invariant tests, and hands-on labs. You do not need to adopt the AsiBackbone package or any specific framework to use the material.

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

Version boundary: Learning 1.0 remains the historical AsiBackbone 6.0 baseline. Use the AsiBackbone 7.0 Compatibility and API Boundary for current implementation syntax; use the Learning 1.0 and AsiBackbone 6.0 Compatibility Guide for the versioned 6.0 record.

Start Here

Choose the shortest path that matches how you want to learn:

If you want to... Start here
Understand the architecture from the beginning Decision Before Execution
Solve a specific architecture problem Find Your Path
See the complete curriculum visually Learning Path Map
Learn by running code Executable Samples
Copy or prepare current AsiBackbone 7.0 API syntax AsiBackbone 7.0 Compatibility and API Boundary
Maintain the historical Learning 1.0 / 6.0 contract or translate older 5.x material Learning 1.0 and AsiBackbone 6.0 Compatibility Guide
Practice by changing or challenging the design Hands-On Labs
Compare a simpler alternative When ASP.NET Core Authorization Is Enough

New to the project? Start with Decision Before Execution and work through the five-part foundation in order. If you already know the problem you need to solve, Find Your Path can route you directly to the most relevant material.

The Architecture in 30 Seconds

The Learning material repeatedly separates proposing an action from authorizing and executing it:

Proposed Intent
   ↓
Policy Context
   ↓
Constraints
   ↓
Explicit Decision
   ↓
Acknowledgment when required
   ↓
Scoped Authority
   ↓
Host-Owned Execution
   ↓
Audit Evidence

The two boundaries to remember are:

Acknowledgment ≠ Authorization ≠ Execution Authority

The model may propose. The host retains execution authority.

In practice, this means the governance layer can determine whether an operation should proceed without becoming the component that performs the real-world operation itself.

Core Terms

  • Intent — the action being proposed.
  • Policy context — the facts needed to evaluate that proposal.
  • Constraints — the rules or conditions that shape what is allowed.
  • Decision — an explicit outcome such as allow, deny, defer, require acknowledgment, or escalate.
  • Acknowledgment — a deliberate acceptance boundary when one is required before proceeding.
  • Scoped authority — narrow, temporary authority to perform a specific operation.
  • Host-owned execution — the application or execution host performs the consequential action.
  • Audit evidence — structured records explaining what was proposed, evaluated, authorized, and executed.

Five-Part Foundation

The foundation is deliberately progressive. Each topic adds one boundary to the same governed-execution model.

Step Topic Core invariant Continue with
1 Decision Before Execution Denied decision → no execution Lab
2 Policy Context and Explicit Decision Outcomes Decisions are explicit, not boolean-only Lab
3 Decision Receipts and Acknowledgment Acknowledgment does not grant execution authority Lab
4 Scoped Capability and Host-Owned Execution Expired or stale authority blocks execution Lab
5 Governed AI Tool Gateway Unknown or unauthorized AI tool proposal → no execution Lab

The fifth topic is the capstone. It combines intent, policy context, explicit decisions, acknowledgment, scoped authority, host-owned execution, and audit evidence into one governed AI-assisted workflow.

How Learning Works

Each foundational topic is reinforced across four complementary forms:

Tutorial
   ↓
Runnable Sample
   ↓
Architectural Invariant Tests
   ↓
Hands-On Lab

Tutorials explain. Samples demonstrate. Tests verify. Labs make you decide.

Tutorials

Tutorials begin with the problem, show the common or naive implementation, expose its failure mode, and then introduce the architectural pattern, tradeoffs, alternatives, and working repository references.

Samples

The samples/ area contains intentionally small .NET teaching implementations. They favor deterministic local behavior, explicit execution boundaries, focused domain examples, and simulated side effects where appropriate.

They are teaching artifacts rather than production frameworks.

Their local types are not package API signatures. Use the AsiBackbone 7.0 Compatibility and API Boundary when you need exact current namespaces, supported construction paths, security changes, or migration guidance.

Tests

Sample tests make important architectural claims repeatable and observable. Typical invariants include:

Denied Decision → No Execution
Expired Capability → Execution Blocked
Unknown AI Tool → Proposal Rejected → No Execution

Their purpose is architectural verification, not broad code-coverage demonstration.

Labs

Hands-On Labs ask you to modify, critique, repair, or extend the design. Exercises may require you to identify hidden side effects, separate evaluation from execution, preserve acknowledgment boundaries, validate scoped authority, detect stale authority, threat-model an AI tool gateway, or compare alternatives.

Where the Pattern Applies

The core separation is broader than AI. The same reasoning can help with:

  • administrative operations,
  • deployment workflows,
  • infrastructure changes,
  • sensitive data access,
  • background jobs,
  • human approval workflows,
  • API tool execution,
  • and multi-tenant policy decisions.

Use the smallest architecture that preserves the boundaries you actually need. In some applications, ordinary ASP.NET Core authorization is enough; in others, the proposal → decision → scoped authority → execution separation adds useful control and evidence.

Working Repository References

AsiBackbone Learning is the educational layer of the organization. The working repositories provide fuller implementation examples:

  • AsiBackbone/AsiBackbone — a .NET governance and policy-control framework covering policy evaluation, structured decisions, acknowledgment workflows, audit/provenance, capability-scoped authority, host-owned execution, and AI/application governance.
  • AsiBackbone/NetCoreApplicationTemplate — an enterprise-oriented ASP.NET Core reference implementation demonstrating middleware organization, structured logging, security defaults, error handling, rate limiting, authentication-ready architecture, data access, and Architecture Decision Records.

Learning uses these repositories as architectural specimens while keeping its teaching examples intentionally smaller and easier to study.

Adoption Is Optional

The goal is to make the reasoning clear enough that you can evaluate, adapt, challenge, or reuse the patterns in your own systems.

You are encouraged to reimplement a pattern differently, remove unnecessary complexity, identify cases where a simpler design is better, compare competing architectures, and use the working repositories only as reference material.

Learning may describe a pattern as canonical when it aligns with the current organization repositories, or alternative when it solves the same problem differently. Canonical does not mean universally correct, and alternative does not mean incorrect.

For a concrete comparison, see When ASP.NET Core Authorization Is Enough.

Scope and Boundaries

AsiBackbone Learning is an educational and architectural resource. It is not a compliance certification, legal standard, security guarantee, AI model, AGI/ASI implementation, robotics controller, or substitute for application-specific security review.

Production systems remain responsible for their own authentication, authorization, infrastructure, persistence, safety controls, regulatory requirements, threat modeling, and operational execution.

Where to Go Next

After completing the foundation, continue into the area that matches your problem:

  • Architecture — patterns, comparisons, boundaries, and system structure.
  • ASP.NET Core — application-level integration and implementation concerns.
  • Security — trust boundaries, failure modes, and defensive architecture.
  • AI Integration — governed AI-assisted workflows and tool execution.
  • Advanced — deeper or more experimental material.
  • ROADMAP.md — current priorities and longer-term direction.

The repository intentionally favors depth before breadth: a well-connected tutorial with runnable code, meaningful tests, a useful lab, and clear implementation references is more valuable than several disconnected pages.

Participate

You can contribute without writing framework code. Questions, corrections, tutorials, labs, diagrams, alternative implementations, failure-mode analysis, architecture critiques, better examples, and documentation improvements are all useful.

Next Step

Begin with Decision Before Execution, then follow the foundation through Governed AI Tool Gateway.

If you already know what you need, use Find Your Path instead.


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