A suite of independent, AI-native .NET packages purpose-built for complex-domain insurance, healthcare, and lending systems. Use one package or all ten — they compose cleanly.
Each package addresses one cross-cutting concern. Independent by design — no forced coupling, no monolith.
Virtual schema layer — multi-source federation, property name translation, and instance graph contracts. Declare how SQL, document stores, and OpenAPI sources map to your business model. AI-friendly by design.
Object graph traversal — fetch entity trees from any backing store via a concise
selection DSL. Fans out concurrently; partial success is first-class. Returns
JsonDocument or
XDocument.
Template string interpolation — resolver chain, JSON path, pipe formatting, nested
token resolution. Renders {ClaimAmount|decimal:C2} against any
JsonDocument context.
Composable rules engine with store-backed rule sets. Evaluates named rule sets against a JSON context. Built-in operators: equality, comparison, IN, wildcards, null checks. Integrates with nc.Solution's virtual schema.
Operation dispatch with typed handlers and a composable middleware pipeline.
Decouples callers from implementations. Handlers are DI-registered and identified
by a MethodSignature DSL — no direct type coupling.
Append-only audit log keyed by entity, actor, and correlation ID. Captures before/after snapshots. Wave 3 adapters: EF interceptor, trigger tables, SQL Server CDC / Postgres logical replication.
Extranet access control — AWS-policy-style wildcard matching, specificity resolution, and a trigger-maintained bulk entity-access store for performant SQL filtering. Handles broker, carrier, and portal access patterns natively.
Attach arbitrary key-value metadata to any entity without schema changes. Transparent
flat JSON at web boundaries via
[JsonExtensionData].
API consumers see no metadata wrapper.
Template storage, semantic versioning, and behavioral contracts. Governs status lifecycle and repeatability rules. Flat JSON seam compatible with nc.Rules and nc.Interpolation — plug into your AI pipeline at any step.
Full-stack wiring — a single
AddNascacht()
entry point. Config-section-driven selective registration: only packages with a matching
appsettings.json
section are wired. No reflection, no scanning.
Adapter packages (nc.Graph.EF,
nc.Audit.EF,
nc.Metadata.Redis, …) ship separately
so core packages stay free of infrastructure dependencies.
nascacht ships with the patterns that matter in regulated, relationship-heavy industries.
Every nascacht package is built against a strict set of constraints — so your application stays clean at every layer.
Wave 1 core packages depend only on Microsoft.Extensions.*.Abstractions
and BCL. Infrastructure dependencies (EF, Redis, SpiceDB) live exclusively in Wave 3
adapter packages. Your app's dependency graph stays clean.
Public types are registered and resolved via the DI container. Three-layer entry
points (zero config, IConfiguration section, delegate)
let consumers start simple and add configuration without rethinking their wiring.
All collection-returning methods return IAsyncEnumerable<T>.
No hidden buffering. Callers materialise when they need to — your memory profile
stays predictable under load.
No generic IRepository<T>.
Each package defines the precise contract it needs — implementors decide what's
feasible for their backing store. EF, DynamoDB, Redis, and custom sources are
all first-class citizens.
No runtime reflection, no attribute-driven DLL scanning. Configuration presence
in appsettings.json is the registration
gate — compile-time safe, debuggable, readable.
All packages target netstandard2.0,
net8.0, and
net10.0.
Run on .NET Framework via netstandard2.0 or take advantage of the latest BCL APIs on
.NET 10 — no code changes required.
Wire once. Chain as many packages as you need. Every package follows the same pattern.
// appsettings.json controls which packages are wired — section present → package active services.AddNascacht("LoanOrigination", configuration);
// appsettings.json { "Nascacht": { "SolutionName": "LoanOrigination", "Interpolation": { "MaxDepth": 50 }, "Security": { "DefaultEffect": "Deny" }, "Dispatch": {} } }
services.AddNascachtSolution("LoanOrigination") .AddSource(new SourceDescriptor("loans_db", SourceKind.Sql)) .AddSource(new SourceDescriptor("zillow", SourceKind.OpenApi)) .AddModel(new ModelDefinition("Loan", "loans_db", PropertyMappings: [ new("LoanNumber", "loan_number"), new("Amount", "origination_amount"), ])) .AddRelationship(new RelationshipDefinition("Loan", "Payment", "Id", "LoanId")) .Services .AddNascachtGraph();
// Fetch the loan graph, evaluate eligibility, render a notification public class LoanNotificationService( IObjectGraph graph, IGraphSelectionParser parser, IRuleService rules, IInterpolationService interpolation) { public async Task<string> RenderApprovalAsync(string loanId, CancellationToken ct) { var selection = parser.Parse("Loan { Amount Status Insured { Name } }"); var context = await graph.GetContextAsync("Loan", loanId, selection, ct); var eligible = await rules.EvaluateAsync("ApprovalEligibility", context.ToDocument()); if (!eligible.Passed) return "Declined"; return await interpolation.InterpolateAsync( "Dear {Insured.Name}, your loan for {Amount|decimal:C2} is approved.", context.ToDocument(), ct); } }
Pick the packages you need, wire them in minutes, and ship intelligent LOB software on the .NET stack you already know.