AsiBackbone

7.5.2 is the current stable release on main.

7.5.2 updates Microsoft dependency versions, Aspire sample hosting, and FsCheck test tooling while preserving public APIs and durable contracts. See the 7.5.2 release notes; consumers moving from 6.x must still follow the 6.x to 7.0 upgrade guide.

A governance framework for accountable .NET decision flow.

AI may provide the intellect. AsiBackbone provides the accountable spine.

AsiBackbone is the implementation package family for Accountable Systems Infrastructure (stable 7.5.x).

Documentation ownership

AsiBackbone/AsiBackbone is the source of truth for the concrete product: package installation and configuration, public APIs and type behavior, runtime semantics, integration boundaries, security posture, operations, compatibility, releases, and maintainer evidence.

For organization-level concepts, architecture education, terminology lineage, tutorials, comparisons, tradeoffs, labs, and general governed-execution teaching, use AsiBackbone Learning and its source repository as the canonical educational source. Learning does not define or override released AsiBackbone package, API, configuration, or runtime behavior.

See the cross-repository documentation ownership contract for the full routing matrix.

---

The practical problem

Most software can tell you what happened. Far less can show that an action was evaluated before it executed: which rules shaped the decision, which policy version applied, whether acknowledgment was required, how follow-on authority was scoped, and where the host took responsibility for execution.

AsiBackbone is a .NET package family for that decision boundary. It helps a host application build safe policy context, evaluate constraints, return a structured decision, preserve a decision receipt, optionally scope continuation, and then let the host decide whether and how to execute.

Is it a good fit? Consider AsiBackbone when a consequential host-owned action needs policy provenance, acknowledgment, scoped continuation authority, or durable decision evidence. Prefer ordinary framework authorization, application services, and logs when the action is low risk and those simpler boundaries already provide the evidence you need. See Adoption and Target Use Cases for the detailed product-fit and simpler-design guidance.

Implementation-first mental model

A normal API adoption path looks like this:

HTTP request
  -> host builds safe evaluation context
  -> host-owned rules evaluate the request
  -> AsiBackbone returns a GovernanceDecision
  -> host writes a decision receipt
  -> host continues only when decision.CanProceed is true

Use plain engineering translations first:

Term	Practical meaning
Policy decision pipeline	Rules evaluate request facts and return a structured decision.
Decision receipt	Record of a decision, its outcome, and its reasons.
Acknowledgment	Confirmation before a risky operation.
Capability grant	Short-lived scoped permission.
Outbox	Durable records awaiting reliable delivery.
OpenTelemetry projection	Optional traces/metrics projection after local records exist.
Host-owned execution	The application code that performs or refuses the protected operation.

First code path

The snippet below is an intentionally small README slice, not a complete Program.cs. It shows the primary governance path: build safe context, evaluate policy, write decision receipt, and let the host execute only after the decision allows it. The full compile-ready walkthrough lives in First 15 Minutes: Standard API Gating.

Note: it is recommended in production environments that reason codes stay in decision receipt rather than client responses

// Registration: Core evaluator + one host-owned rule + local in-memory decision receipt sink.
builder.Services.AddAsiBackboneAspNetCore();
builder.Services.AddSingleton<InMemoryAuditLedger>();
builder.Services.AddSingleton<IDecisionReceiptSink>(sp =>
    sp.GetRequiredService<InMemoryAuditLedger>());
builder.Services.AddSingleton<IGovernanceConstraint<GovernanceEvaluationContext>, AllowedRegionConstraint>();
builder.Services.AddSingleton<IGovernancePolicyEvaluator<GovernanceEvaluationContext>>(sp =>
    DefaultGovernancePolicyEvaluator.CreateBuilder<GovernanceEvaluationContext>()
        .AddConstraints(sp.GetServices<IGovernanceConstraint<GovernanceEvaluationContext>>())
        .WithOptions(new GovernancePolicyOptions())
        .Build());

app.MapPost("/api/orders/{region}/approve", async (
    string region,
    HttpContext httpContext,
    IGovernancePolicyEvaluator<GovernanceEvaluationContext> evaluator,
    IDecisionReceiptSink auditSink,
    CancellationToken cancellationToken) =>
{
    var metadata = new Dictionary<string, string>(StringComparer.Ordinal)
    {
        ["operation"] = "orders.approve",
        ["region"] = region,
        ["risk"] = "routine-api-write"
    };

    var context = new GovernanceEvaluationContext(
        correlationId: httpContext.TraceIdentifier,
        policyVersion: "policy-v1",
        policyHash: "policy-hash-v1",
        metadata: metadata);

    GovernanceDecision decision = await evaluator.EvaluateAsync(context, cancellationToken);

    DecisionReceipt receipt = DecisionReceipt.FromDecision(
        GovernanceActorContext.Human("example-user", "Example User"),
        operationName: "orders.approve",
        decision,
        metadata: context.Metadata);

    await auditSink.WriteAsync(receipt, cancellationToken);
    if (!decision.CanProceed)
    {
        return Results.Json(new
        {
            allowed = false,
            decision = decision.Outcome.ToString(),
            decision.ReasonCodes,
            auditEventId = receipt.EventId
        }, statusCode: StatusCodes.Status403Forbidden);
    }

    // Host-owned execution starts here. AsiBackbone does not approve the order itself.
    return Results.Ok(new
    {
        allowed = true,
        message = "Host order approval would run after this governance decision.",
        auditEventId = receipt.EventId
    });
});

The 4.x evaluator defaults are intentionally fail-closed for governed surfaces: empty policy structures deny, eligible ordinary constraint exceptions deny with asibackbone.policy.constraint_exception, and threat-contributor exceptions deny. Set TreatConstraintExceptionAsDenial = false only when a host intentionally wants fail-fast exception propagation through its own exception, transaction, retry, telemetry, or incident-response boundary.

For production-style hosts, add durable audit/outbox persistence, signing or verification, DLP/classification, provider emission, and operational monitoring only where the host has explicitly chosen and configured those boundaries.

Package family

Stable 7.x package family. The current release is 7.5.2.

7.5.2 updates Microsoft dependency versions, Aspire sample hosting, and FsCheck test tooling without changing public APIs, durable contracts, or runtime decision behavior. Consumer-visible Microsoft dependency minimums advance to 10.0.14 where declared by the adopted package. The 7.5.0 release added compatible Core context and decision-copy APIs for request trace correlation. The 7.4 minor release added production public-key signature verification and durable EF Core capability-grant replay protection, building on the signed capability grants introduced in 7.3. Package IDs, the net10.0 target, canonical wire values, and binary assembly identity 7.0.0.0 are unchanged.

Consumers upgrading from 6.x must follow the 6.x to 7.0 upgrade guide. Hosts must preserve actor identity across both acknowledgment-challenge legs and remap persisted numeric DLP enum values.

Package	Version	Downloads	Role
AsiBackbone.Core			Framework-neutral governance primitives: decisions, constraints, threat-model contributor hooks, acknowledgments, decision receipt, lifecycle events, governed execution receipts, capability grants and their signed capability grant token transport encoding, explicit capability-grant validation profiles and proof trust pinning, durable outbox contracts, provider-neutral emission contracts, DLP/classification policy primitives, signing-ready metadata, canonical hashing/signing seams, verification-policy primitives, policy evaluator options, metadata budget helpers, and builder-style decision receipt construction.
AsiBackbone.DependencyInjection			Explicit AddAsiBackbone(...) builder facade for coordinating host-selected provider registrations without making Core own infrastructure.
AsiBackbone.Storage.InMemory			Non-durable in-memory storage helpers for tests, samples, local validation, lifecycle events, and outbox proof paths.
AsiBackbone.EntityFrameworkCore			EF Core model configuration and host-owned persistence for audit ledger, acknowledgments, lifecycle events, JSON metadata storage, and outbox records.
AsiBackbone.AspNetCore

Runtime decision-receipt signing remains provider-neutral through AsiBackbone.Signing.ManagedKey. AsiBackbone does not ship first-party Azure Key Vault, AWS KMS, GCP Cloud KMS, HSM, certificate-store, enterprise KMS, or production-style signing sample-host implementations. Future Event Hubs, Purview, gateway, robotics, immutable-storage, or other non-signing provider packages are not part of the stable contract unless separately reviewed and released.

Supported target framework

Stable 7.x packages intentionally target net10.0. Consumers should plan on a .NET 10 SDK/runtime or later for the current package line.

The project is not multi-targeting .NET 8 for 7.x. That is an explicit adoption decision, not a defect workaround. The current package family uses a single repository-wide TargetFramework of net10.0, the EF Core integration is aligned with centrally managed EF Core 10.0.x dependencies, and backporting the full package, analyzer, template, CI, packaging, and smoke-test surface would add compatibility overhead for a short-lived adoption window.

If meaningful external consumer demand appears, additional TFM support can be reconsidered in a later release with CI, packaging validation, analyzer compatibility, template smoke tests, and documentation updated together. See the Target Framework Support Decision Record.

Choose your path

Use the organization as one connected path; each repository has a distinct job:

1. Learn the pattern: start with AsiBackbone Learning for concepts, tutorials, labs, comparisons, and adoption personas.
2. Try a complete host: use NetCoreApplicationTemplate when you want a production-oriented ASP.NET Core baseline to evaluate or adapt.
3. Adopt the packages: return here for the implementation-first path, install only the AsiBackbone.* packages your host needs, and validate one low-risk governed operation before expanding.

Already evaluating or using the project? See the public adopter registry and use its report form to share permission-based adoption evidence or feedback.

Start here

For implementation-first adoption:

• Implementation-First Adoption Path — plain engineering translations and the recommended first reading path.
• First 15 Minutes: Standard API Gating
• AddAsiBackbone Builder Facade
• dotnet new Templates
• Target Framework Support Decision Record
• Reference Deployment: Plain ASP.NET Core Host Evidence
• Testing Harness
• Strict Governance Profile
• Threat Model Contributors
• Project Boundaries and Non-Claims
• Terminology Map
• Progressive Adoption Ladder
• Production Managed-Key Integration Guide

For optional conceptual background:

• Intent to Execution: An Accountability Pattern
• Core Governance Flow Diagrams
• ASI Backbone Concept Synopsis
• Acknowledgment Workflow
• Core Domain Language
• Host-Owned Execution Enforcement

The full, categorized documentation set lives at the documentation site.

Current status

The current stable release is 7.5.2. It updates Microsoft dependency versions, Aspire sample hosting, and FsCheck test tooling while preserving public APIs, durable schemas, canonical wire values, package IDs, the net10.0 target, and runtime decision behavior. Declared Microsoft dependency minimums advance to 10.0.14.

Managed assemblies retain binary identity 7.0.0.0 throughout the compatible 7.x line.

The stable API contract is documented in API Compatibility and SemVer. The release is described in 7.5.2 Release Notes; the preceding trace-correlation additions are described in 7.5.0 Release Notes. Consumer verification evidence is recorded in the 7.5.2 Consumer Verification Guide. Consumers moving from the previous stable line must follow the 6.x to 7.0 upgrade guide. Major Version History and Upgrade Cost explains why each major version since 1.x was necessary and what each upgrade costs. Earlier release records remain available for historical traceability.

Support and project stewardship

• Use the Support Policy to choose between discussions, issues, and private vulnerability reporting and to review the version-support lifecycle.
• Report sensitive concerns through the repository Security Policy.
• See Maintainers for current operational and publishing ownership.
• See Governance for authoritative roles, decisions, triage, and release policy.
• See Adopters for public adoption evidence and the opt-in reporting path.

Relationship to NetCoreApplicationTemplate

NetCoreApplicationTemplate may be used as a preferred host baseline during development and validation, but AsiBackbone does not require it.

NetCoreApplicationTemplate = preferred host baseline
AsiBackbone               = optional governance/module package family
Consumer application      = chooses whether to use either or both

A consumer should be able to use AsiBackbone in an application generated from NetCoreApplicationTemplate, in an existing ASP.NET Core application, or in a custom host that provides the required infrastructure. See NetCoreApplicationTemplate Host Validation.

Alignment boundary

AsiBackbone is a governance framework, not an intelligence engine. It implements software primitives for accountable decision flow and keeps execution authority with the host application. See Project Boundaries and Non-Claims for the full scope statement and safe wording guidance.

Current NuGet packages are intentionally published without package signing. The dated NuGet Package Signing Decision Record records the accepted risk, compensating controls, mandatory review date, and early re-evaluation criteria. The project publishes durable release-attached SBOMs, package/SBOM provenance, Source Link metadata, and package hashes as distinct trust signals; none is presented as a signed-package guarantee. For verification guidance, see the 7.5.2 Consumer Verification Guide and 7.5.2 Release Notes.

Design principles

• Keep Core small.
• Keep Core dependency-light.
• Avoid hidden host assumptions.
• Prefer explicit integration over magic.
• Let the host own infrastructure.