Provider and runtime ownership

Providers make external native APIs visible as legal TypeScript declarations and map selected source identities to target operations.

Provider declaration flow

native metadata or declarative model
  -> immutable provider declaration model
  -> provider-backed virtual TypeScript module
  -> TSTS source checking and source overload selection
  -> exact provider identity on selected evidence
  -> target operation relation
  -> target AST

For example:

import { List } from "@tsonic/dotnet/System.Collections.Generic.js";
const values = new List<string>();
values.Add("one");

The .NET provider supplies legal TypeScript declarations for the generic type, constructor, and overload family. TSTS selects one source signature. The C# provider relation then selects the exact native member from that source identity. Neither phase chooses by the string Add alone.

Canonical identity

Provider module, export, member, signature, parameter, and type identities are opaque semantic identifiers. Physical generated filenames, import aliases, source spelling, overload-group names, and target text are not identity.

Provider declarations are immutable snapshots. Recursive provider graphs may share canonical declarations, but contradictory declarations fail closed.

Packaged providers

Both targets expose a package-composition factory through their provider SDK:

Target	Factory	Native relation data
C#	createCsharpProviderPackage	C# type/member relations and policy contribution
Rust	createRustProviderPackage	Rust type/operation rows and Cargo requirements

The target SDK owns reusable registration and declaration transport. The capability owns its modules, aliases, source declarations, native mappings and runtime artifacts. Node declarations live under provider/modules/; package composition lives in provider/package.ts. Neither the host nor the SDK branches on Node module names.

For example, statSync(path) has a declared Stats result on both targets. The C# capability relates that result to its native Stats class; Rust relates it to its native carrier. The same ownership flow does not require identical native member schemas or identical runtime directory layouts.

See the C# provider API and Rust provider API for each factory’s native contract.

Runtime ownership

Runtimes implement operations already selected by target analysis:

• base runtimes contain carriers required without optional surfaces;
• JS runtimes implement JavaScript source-profile operations;
• Node runtimes implement installed Node capability operations.

Runtime code does not discover which source operation was intended. It does not inspect arbitrary target objects or repair missing compile-time evidence.

Project contributions

Capabilities and providers contribute target-native references explicitly:

• assembly references for C#;
• crate paths, features, and registry-patch relationships for Rust.

The host combines declared contributions and rejects conflicts. It never infers a dependency from an import spelling or copied runtime directory.