Fabric Artifact

This document defines the persistent artifact boundary for finalized Fabric hardware descriptions. Fabric dialect specifications own hardware semantics; this document owns only root variants, dependency framing, canonical bytes, identity, finalization, and publication.

Artifact Family And Root Variants

The current persistent family is:

loom.fabric 7.1

ArtifactSchemaDescriptor {
  identity = "loom.fabric"
  version = 7.1
}

FabricRoot =
    Module
  | System
  | InterconnectImplementation

The X.Y rule classifies the semantic change between schema definitions: changing X is incompatible, while increasing Y adds a non-breaking semantic extension without changing existing field meanings. It does not make schema descriptors interchangeable at the persistent boundary. The Common Artifact descriptor is part of the identity preimage, and each Fabric owner accepts and emits exactly the descriptor it implements. Reading, defaulting, or upgrading an object with a different minor version requires an explicit owner-defined migration that re-finalizes the object under a new identity; minor-version proximity alone never authorizes a compatibility reader.

Version 4.0 is one atomic breaking boundary. It retains the complete 3.0 memory-plane, connection, identity, and root contracts while changing one execution invariant: a selected Buffered fabric.fifo cuts both forward-valid and backward-ready combinational dependencies, and a cycle-start-full queue does not admit an enqueue from current-cycle downstream readiness. A Fabric Version 4.0 accepted and emitted only its exact descriptor; there was no 3.x compatibility owner, fallback importer, in-place upgrade, or alternate identity path. Reinterpreting a 3.x FIFO would change selected handshake-cycle legality and cycle timing. The RootRelative memory index-width relation introduced in 2.0 and the exact System service-endpoint attachment introduced in 3.0 remain part of this boundary.

Version 4.1 is a non-breaking semantic extension of the 4.0 message-transfer capability domain under the X.Y rule above. In addition to its canonical finite set of exact payload types, a message endpoint may carry one canonical fixed-vector family and one canonical finite set of exact stable-integral pointer formats. The vector family stores exact scalar element types, a positive maximum row-major-flattened payload width, and a positive maximum rank no greater than the canonical type codec's rank limit. A concrete vector is admitted exactly when it is fixed, has positive dimensions, uses one listed element type, stays within both bounds, and has a canonical type encoding. A pointer is admitted exactly when the application module's DataLayout-derived address space, representation width, address width, and layout kind equal one listed format. Neither family infers semantic compatibility from equal widths or replaces exact scalar entries. The new family and pointer-format fields are appended to the message-domain wire record; all earlier 4.0 field tags and meanings are unchanged. A Version 4.1 owner accepted and emitted only its exact descriptor.

Version 5.0 is one atomic breaking boundary for Temporal PE configuration ownership. fu_config_mode is now the closed typed #fabric.fu_config_mode<...> hardware-organization attribute. The prior string spelling and the authoring-only pe_enable, instruction_mem, and per_fu_sw_configs attributes are not accepted. Selected instruction state exists only in the Mapping-derived configured view and ConfigurationImage. Because this changes the canonical Module grammar and removes a competing configuration authority, the Version 5.0 owner accepted and emitted only its exact descriptor. There was no 4.x compatibility owner, string alias, fallback importer, or in-place upgrade.

Version 6.0 is one atomic breaking boundary for System hardware-domain membership. A SpatialCore member is occurrence-qualified through the selected AccCore and Module domain slot, so two occurrences of one imported Module no longer collapse to the same template-local owner. The hardware-domain record, canonical System relation, typed member codec, and derived effective-domain queries all use that one FabricHardwareDomainMemberRef contract. Reinterpreting a Version 5.0 member would lose occurrence identity, so the Version 6.0 owner accepted and emitted only its exact descriptor. There was no 5.x compatibility owner, fallback importer, or in-place upgrade.

Version 7.0 is one atomic breaking boundary for programmable System transport configuration. A resource explicitly authored with Configuration pattern selection owns one direct semantic field whose bit positions are its exact canonical pattern ordinals. Dynamic selection owns no field regardless of pattern count. The complete Interconnect refinement, packed ConfigurationABI, and SystemMapping configured projection all consume that field. Reinterpreting a Version 6.0 System would change its field inventory while retaining the same root identity, so the current owner accepts and emits only the exact loom.fabric 7.0 descriptor. There is no 6.x compatibility owner, fallback importer, or in-place upgrade.

Version 7.1 is a non-breaking semantic extension of the 7.0 FIFO domain under the X.Y rule above. A fabric.fifo may declare a typed queue_discipline: strict_fifo retains the exact 7.0 semantics, while per_tag_virtual_channel schedules dequeue among per-Physical-Tag channel heads over one shared queue pool, owns an OfferAdvance internal arbitration transition, and qualifies its dequeue and offer uses by the exact tag value they present. The attribute is optional and absent selects strict_fifo, so a 7.0 canonical payload is byte-identical to its 7.1 StrictFifo re-finalization; only the descriptor framing and any rewritten dependency rows change identity. The extended use-pattern value-schema parameters codec field, previously reserved and rejected, is admitted for exactly these tag qualifications. A 7.0 root and its 7.1 re-finalization are never interchangeable: the ordinary 7.1 importer accepts and emits only the exact loom.fabric 7.1 descriptor, and reading a 7.0 root requires the explicit migration owner migrateFabricRootV7_0ToV7_1, which recursively re-finalizes the direct dependency closure under 7.1, publishes each result, and independently reverifies it through the complete strict 7.1 import. Migration yields a new ArtifactIdentity, so every Mapping, ResolvedConfig, and evaluation provenance naming the 7.0 root no longer resolves and must be regenerated against the migrated root.

The 4.0 fabric.system.connection relation retains both its Transport and MemoryService variants from 3.0. These remain required operation-service endpoint references and direct identity connections, not an optional extension or a second connection schema. Omitting required direct memory-service edges cannot be repaired by endpoint matching in a consumer.

The three variants share one artifact family because they use the same Fabric semantic model, reference framing, canonicalization rules, and finalization boundary. They retain distinct typed root payloads and verifiers. The variant tag cannot be inferred from a symbol name, path, or MLIR operation order.

Module is one SpatialCore hardware template. System is one architecture- only multi-core Fabric system. InterconnectImplementation is the exact protocol and implementation sibling for one System; it refines, but never redefines, that system's Transport Architecture.

Each root variant has one typed MLIR root operation and no substitute:

Module                     -> fabric.module
System                     -> fabric.system
InterconnectImplementation -> fabric.interconnect_implementation

The authoring builtin.module is only a symbol and dependency-resolution container. It is never the persistent root payload. A root-kind tag paired with a different operation, a generic module payload, or a caller-declared root kind is structurally invalid. If a running Loom build has not registered the exact typed operation, canonical codec, importer, and semantic verifier for a known root variant, that variant fails closed as Unsupported(FabricRootProviderUnavailable). It cannot fall back to another root operation. This is distinct from fabric_artifact_owner_contract_unavailable, which means the schema itself has no enabled owner contract, as for ImplementationInput in schema 7.x.

There is no persistent finalized-design wrapper, separate family per variant, or generic hardware manifest.

Direct Dependencies And Derived Closure

Every direct dependency is an exact Common ArtifactRootReference. Artifact roots are never encoded as ArtifactReference<T>, a reserved owner-local kind, or a sentinel target. When a root payload addresses a target inside a direct dependency, it stores the dependency-table ordinal plus that owner's canonical local target bytes. This compact form mechanically recovers the complete ArtifactReference<T> and does not create another reference authority.

The dependency-role catalog remains unchanged in loom.fabric 7.1:

ImportedModule       = 0
RefinedSystem        = 1
ImplementationInput  = 2  // reserved-unavailable in schema 7.x

A Module root admits no direct dependency: every authoring template use is fully elaborated into the canonical Module and no fabric.instantiate survives. A System root admits only ImportedModule. An InterconnectImplementation root admits exactly one RefinedSystem and no other direct dependency in schema 7.x. ImplementationInput = 2 retains its wire ordinal so schema 7.x never renumbers a published discriminant, but it has no accepted artifact family, schema version, root kind, owner-local target kind, or dependency-use contract in schema 7.x. It is therefore not an enabled dependency role and cannot appear in a canonical Fabric root.

The enabled schema-7.1 dependency contracts are exact:

ImportedModule:
  owner schema = loom.fabric 7.1
  required root = Module

RefinedSystem:
  owner schema = loom.fabric 7.1
  required root = System

A pre-7.1 Module or System has no 7.1 dependency contract and is rejected rather than republished under a new identity without exact finalization; the only 7.0-to-7.1 path is the migration owner above. Likewise, a RefinedSystem dependency cannot cross a Fabric schema version or name a Module or InterconnectImplementation root. A later compatible Fabric minor version must explicitly publish its own dependency-contract table; role ordinals alone never imply cross-version admission.

An authoring draft, encoder input, or imported envelope containing an ImplementationInput row fails structurally with fabric_artifact_owner_contract_unavailable before the referenced object is looked up or imported. The ordinal is not permission to accept an arbitrary ArtifactRootReference, protocol name, blob, path, or property bag. A later Fabric schema version may enable the role only by defining a finite table of exact accepted contracts. Each table entry must fix the dependency owner's ArtifactSchemaDescriptor, required root kind, any admitted owner-local target kind and canonical codec, and one closed dependency-use validator. The role ordinal alone never owns those facts.

Dependency use is determined by the static field that contains the compact reference. There is no generic dependency-use tag, path, or property bag. The closed schema 7.x field catalog is:

System AccCore spatial_core
  role: ImportedModule
  target: FabricModuleTemplateRef

System spatial_attachment module endpoint
  role: ImportedModule
  target: FabricModuleBoundaryEndpointRef

System hardware_domain SpatialCoreSlot member
  role: ImportedModule
  target: FabricModuleDomainSlotRef selected through the member's AccCore

InterconnectImplementation refined_system
  role: RefinedSystem
  target: root only

InterconnectImplementation EndpointRefinement architecture target
  role: RefinedSystem
  target: FabricTransportEndpointRef

InterconnectImplementation ResourceStateRefinement architecture target
  role: RefinedSystem
  target: FabricResourceStateRef

InterconnectImplementation TransferPatternRefinement architecture target
  role: RefinedSystem
  target: FabricTransferPatternRef

InterconnectImplementation ConfigurationRefinement architecture target
  role: RefinedSystem
  target: FabricSemanticConfigFieldRef

Each targetful field encodes exactly u64be(dependency_table_ordinal) followed by the dependency owner's canonical local-target bytes. The root-only field encodes only the ordinal. The decoder obtains the required role and target type from the field schema, checks the ordinal and role, invokes the dependency owner's strict local-reference decoder, validates the target against the exact imported root view, and requires decode/re-encode equality. A row is used when at least one valid field, including the root-only refined_system field, references its ordinal. After walking the complete typed root, every direct dependency row must have been used and every external use must resolve to one row. Duplicate uses are legal; duplicate or unused rows are not.

A repeated use of one enabled dependency repeats its table ordinal in the payload; it does not duplicate the dependency row. Rows are sorted by (role, ArtifactRootReference canonical bytes) and exact duplicate rows are invalid.

An occurrence-qualified Module slot or internal target in a System does not add another direct dependency use. Its SpatialCoreOccurrenceRef selects the AccCore's already-declared ImportedModule row, and validation resolves the slot or local target through that exact dependency. The occurrence-qualified reference never repeats a dependency ordinal, Module identity, or dependency row.

The transitive dependency closure is derived mechanically. It is never stored as another list. Every enabled direct dependency must already be durably published as its own Artifact before Fabric root publication begins. After rejecting unavailable roles, the finalizer resolves each exact root reference through Common ArtifactStore::get, invokes that dependency family's strict owner importer, and recursively validates the reachable closure. Common validates object framing, schema, and identity; the dependency owner validates its canonical semantic bytes and root kind; Fabric validates the dependency role, referenced local targets, use, uniqueness, and acyclic closure. None of these layers duplicates another layer's checks.

Missing, foreign, wrong-kind, duplicate, cyclic, or unused direct dependencies make finalization fail before the root put. A dependency publication that is still in flight is either absent or complete to the finalizer; an absent read fails and may be retried rather than waiting on temporary store state.

Builder handles, helper names, preset names, source locations, visualization metadata, file paths, and printer positions are provenance or projections and do not enter dependency identity.

Canonical Semantic Relation And Bytes

Artifact identity is computed from one canonical semantic relation, not from authoring order or raw source text. Canonicalization:

1. materializes an omitted Module relation as the complete single-domain shorthand, or validates and composes every explicitly authored Module-instance domain-slot binding, while expanding every fabric.instantiate needed by the root;
2. resolves typed direct references;
3. strips nonsemantic names, locations, and visualization metadata;
4. constructs one private, identifier-free, structurally root-complete candidate;
5. verifies all dialect, resource, capability, and domain contracts on that complete candidate;
6. selects the lexicographically least canonical serialization among semantic graph isomorphisms;
7. derives and deduplicates canonical FU definitions and Memory Operation Engine definitions, then establishes each concrete occurrence relation;
8. assigns root-local entity identifiers and structural ordinals from that canonical form; and
9. writes one deterministic MLIR bytecode payload in canonical entity order.

For a Module root, that relation includes the canonical symbolic Clock/Reset slot inventory and every Module boundary or internal-owner assignment. For a System root, it includes the canonical occurrence-slot domain memberships. The effective domain of an occurrence-qualified internal target is derived from those two relations and is not serialized as a second expanded member list.

A nested Module's authoring-only slot binding is consumed during expansion. Its child boundary and slot inventory disappear, and its fresh internal owners are assigned directly to the selected slots of the enclosing Module. The binding itself is not a dependency, local reference, canonical root field, or separate identity input. Consequently, equivalent inline and instantiated forms converge on the same complete flat relation.

The exact Fabric canonical semantic bytes passed to the Common Artifact SHA-256 v1 finalizer are:

bytes("loom.fabric.semantic.v7\0")
|| u32be(root_variant)
|| u64be(direct_dependency_count)
|| repeated direct_dependency_count times {
     u32be(dependency_role)
     || u32be(length(dependency.schema.identity))
     || bytes(dependency.schema.identity)
     || u32be(dependency.schema.version.major)
     || u32be(dependency.schema.version.minor)
     || dependency.ArtifactIdentity[32]
   }
|| u64be(canonical_mlir_bytecode_length)
|| canonical_mlir_bytecode

Root variant ordinals are Module = 0, System = 1, and InterconnectImplementation = 2. The dependency-role ordinals above and the root ordinals are preserved from schema 4.x and immutable throughout schema 7.x. Counts and lengths are unsigned big-endian values, there is no padding or native layout, and the decoder rejects truncation, trailing bytes, noncanonical dependency order, duplicates, unused rows, and payload references outside the dependency table. Decoding the known ordinal ImplementationInput = 2 does not make it legal; schema validation rejects it as reserved-unavailable before dependency lookup.

The MLIR payload encodes each external root use as a u64be dependency-table ordinal followed by the referenced owner's canonical local target bytes when a target is required. It does not repeat an ArtifactIdentity. The MLIR bytecode writer's embedded producer tag inside canonical_mlir_bytecode is a frozen encoder token (loom.fabric.3.0) retained solely for canonical byte stability across schema revisions; it carries no version semantics, is never consulted by validation, and changing it would change every canonical identity. The Fabric semantic envelope does not repeat its own schema descriptor because the Common identity preimage already owns that framing. The v7 semantic-domain marker therefore identifies the major-version envelope grammar; it is not a wildcard minor-version admission rule. fabricArtifactSchema remains the sole owner of the complete current version, and strict import compares the root reference against that exact descriptor before decoding the envelope.

The specification fixes the canonical result, not a canonical-labeling algorithm. Individualization-refinement, orbit pruning, or another exact algorithm is an implementation choice. A resource bound may produce typed Incomplete; it may not publish a noncanonical identity.

For one supported Loom codebase and resolved configuration, semantically equal hardware has identical canonical bytes and identity. Different canonical bytes under one digest are an internal error. A semantic hardware difference must change canonical bytes and identity.

Finalization And Publication

Finalization is failure-atomic:

authoring draft
  -> close scopes and helpers
  -> require exactly one typed root operation for the selected root variant
  -> resolve direct typed references
  -> validate root/role cardinality and reject unavailable dependency roles
  -> get and strict-import every already-published direct dependency
  -> recursively validate the exact dependency closure
  -> decode every typed external use and reject missing or unused rows
  -> materialize an entirely omitted Module relation as one Clock and one Reset
  -> validate and compose every Module-instance domain-slot binding
  -> expand instantiations
  -> reject every residual fabric.instantiate
  -> build a private identifier-free root-complete candidate
  -> verify semantic contracts on that candidate
  -> derive canonical FU and Memory Operation Engine definitions
  -> canonicalize and assign local identities and occurrence relations
  -> write canonical bytes
  -> compute the unpublished candidate ArtifactIdentity
  -> import canonical bytes and independently reverify
  -> Common ArtifactStore::put the Fabric root object only
  -> return the published ArtifactRootReference

Envelope encode/decode, dependency-role preflight, and Common identity calculation are necessary prefixes of this pipeline, not a reduced finalization mode. An implementation that has not decoded all typed dependency uses, rejected unused rows, expanded the complete instance graph, built the root-complete semantic view, performed semantic canonicalization, and strictly reimported the result cannot return FinalizedFabricRoot or claim artifact success. It must return the typed unavailable, invalid, incomplete, or store failure owned by the first unsatisfied stage.

Fabric failure atomicity means one root object is complete or absent; it does not mean that the root and its dependency graph become visible in one transaction. Dependencies are independently valid, immutable, shareable Artifacts and may be visible before this root or remain unreachable after a failed root attempt. Fabric defines no multi-object transaction, publication manifest, rollback, or dependency cleanup protocol.

All semantic checks and dependency imports complete before the root's atomic namespace insertion. A store reader may observe the complete root after that insertion but before the publishing call receives its durability acknowledgement; this is safe because the exact dependency closure was already published and validated. The finalizer returns no successful root reference until put reports success. If a crash or artifact_store_io occurs after insertion, recovery retries the same deterministic root publication; the store contains either no root or the complete expected root, never a partial root.

Failure classes retain their existing owners:

• an absent exact dependency is a missing-artifact failure;
• a reserved-unavailable dependency role is fabric_artifact_owner_contract_unavailable and is rejected before lookup;
• a known root variant whose typed root provider is not registered is Unsupported(FabricRootProviderUnavailable);
• a wrong root operation, role, root kind, local target, dependency use, duplicate or unused row, residual instantiation, dependency cycle, or owner-semantic mismatch is structurally Invalid Fabric input; a cycle in the root-complete unconditional handshake graph is specifically Invalid(UnconditionalCombinationalHandshakeCycle);
• malformed dependency storage, key/preimage mismatch, or identity collision is Common store corruption or collision;
• canonicalization resource exhaustion is Incomplete;
• absent backend support remains Unsupported; and
• root publication or durability failure is artifact_store_io and returns no successful root reference for that attempt.

Import uses the same boundary. Common validates the root object, the Fabric importer first validates root/role cardinality and rejects unavailable roles, then recursively resolves and owner-imports its exact enabled dependencies. A sealed FabricArtifactView is produced only after the complete closure passes. A stored root whose dependency later becomes unavailable remains a complete stored object but cannot be imported as a complete Fabric root; import reports the missing or corrupt dependency and never repairs, rewrites, or deletes the root.

Semantic verification uses the structurally complete root relation, not a caller-supplied connection shadow. It validates all resource-local handshake alternatives and rejects a cycle only when every arc in that cycle is unconditional in every legal configured view. It must not union mutually exclusive switch traversals, FIFO modes, tags, or physical refinements into a fabricated active graph. The complete graph for one selected configuration is owned by SpatialMapping or SystemMapping verification under docs/spec-mapping-verification.md.

Cross-instance structure is never validated one template at a time. The private candidate is built only after the complete reachable instantiation graph has been expanded, and any residual fabric.instantiate is invalid. Consequently point connections and resource-local dependencies that close a cycle across former instance boundaries are visible to both the unconditional Fabric structural gate and the later selected Mapping gate.

Immutable Root-Complete Views

The canonical Fabric root is the only authority for its structural relations. The C++ import API exposes those facts through one sealed, immutable FabricArtifactView. That view exists only after canonical IDs and bytes have been assigned, either inside the owner finalizer for independent reimport or through strict import of an existing complete root and dependency closure. It has no public constructor, cannot be subclassed, and cannot be assembled from caller-provided relation fragments.

Pre-canonical semantic verification uses an owner-internal immutable view of the complete identifier-free candidate. It is not FabricArtifactView, has no persistent-reference API, and cannot escape finalization. The finalizer itself derives it from one complete authoring root after closing helpers, resolving references, and expanding instantiations; callers cannot manufacture it or assert completeness.

Tests that need invalid input submit an invalid whole authoring root to the real finalizer or corrupt a complete serialized root for import rejection. They do not call a public freeze hook, subclass FabricArtifactView, or supply partial relation answers.

For every root kind, the view exposes canonical complete ranges for all relations owned by that root, including its entities, owner inventories, token and memory endpoints, directed point connections, and dependency-derived occurrence facts. It also exposes the FU definition inventory, the exact FU occurrence-to-definition relation, each FU definition's canonical capability-template inventory, the Memory Operation Engine definition inventory, and the exact memory-occurrence-to-engine-definition relation. Convenience queries such as fuTemplate(occurrence), fuCapabilityTemplates(template), and memoryEngineTemplate(occurrence) are indexes over those complete ranges, not additional authorities. For a Module root, the view exposes the canonical symbolic Clock/Reset slot inventory and the complete boundary/internal-owner assignment relation. It also exposes the complete canonical token-plane resource-attachment relation. Each FabricModuleBoundaryEndpointRef directly connected to a resource maps to the one occurrence-local FabricTransportEndpointRef reached by that signature input or producing that signature result in the finalized Module body. Unused boundaries and direct boundary-to-boundary passthroughs have no row; the view never invents a resource endpoint for them. This relation is derived from the canonical Module SSA graph and is not another serialized catalog. A Module boundary reference remains an attachment correspondence rather than a transport endpoint, traversal, or capacity owner.

The same Module view separately exposes the complete canonical token-plane boundary-passthrough relation. Each row contains one exact input FabricModuleBoundaryEndpointRef and one exact output FabricModuleBoundaryEndpointRef connected directly by the canonical Module SSA graph. Rows follow output signature ordinal; original signature ordinals are retained even when memory-plane endpoints create holes in the token-plane inventory. Inputs and outputs are each unique in the relation. A boundary present in an attachment row cannot also appear in a passthrough row. The relation contains no resource endpoint, traversal, capacity, EntityId, or serialized payload and does not change Fabric Artifact identity.

Memory-plane Module boundaries remain in the typed memory endpoint model and never appear in this token-plane relation. A System root additionally exposes complete canonical ranges for spatial attachments, hardware-domain declarations and direct or occurrence-slot membership, system transport resources, transfer patterns, and each transport resource's optional crossing contract. The same view derives the complete effective-domain relation for each occurrence-qualified Module boundary and internal target. That derived range is an index over the exact Module assignments and System slot memberships, not another serialized catalog.

All range elements are exact typed Fabric references or immutable views of root-owned records. Ranges use canonical order and contain no duplicates. Convenience queries such as entityKind, hardwareDomainKind, hasPointConnection, membership lookup, or crossing lookup are derived indexes over these same ranges. An implementation may cache the indexes, but a query and a scan of the authoritative range must always agree. A query is never an independent callback authority.

The critical C++ boundary is conceptually:

finalizeFabricRoot(complete authoring root) -> FinalizedFabricRoot
importEntireFabricRoot(ArtifactRootReference,
                       canonical bytes,
                       exact dependencies) -> FabricArtifactView
requireSystemRoot(FabricArtifactView) -> FabricSystemRootView
requireModuleRoot(FabricArtifactView) -> FabricModuleRootView

FabricModuleRootView::domainSlots()
  -> canonical range<FabricModuleDomainSlotRef>
FabricModuleRootView::domainAssignments()
  -> canonical range<ModuleDomainAssignmentView>

FabricArtifactView::pointConnections()
  -> canonical range<FabricPointConnectionPayload>
FabricArtifactView::handshakeOwners()
  -> canonical range<FabricHandshakeOwner>
buildFabricHandshakeContext(FabricArtifactView)
  -> sealed shared structural templates
     + exact occurrence and row bindings
     + unconditional boundary closure
FabricHandshakeContext::ownerModels()
  -> canonical range<HandshakeOwnerModel>
resolveSelectedHandshake(
    HandshakeOwnerModel,
    exact typed owner selection)
  -> canonical range<HandshakeActivationFragmentOrdinal>
deriveUnconditionalHandshakeDependencyArcs(FabricArtifactView)
  -> canonical range<HandshakeDependencyArc>
FabricArtifactView::memoryOperationPorts(FabricMemoryOccurrenceRef)
  -> canonical range<FabricMemoryOperationPortRef>
FabricArtifactView::memoryOperationPort(FabricMemoryOperationPortRef)
  -> exact MemoryOperationPortView
FabricArtifactView::memoryCapabilityAlternative(
    FabricMemoryCapabilityAlternativeRef)
  -> exact MemoryCapabilityAlternativeView

FabricSystemRootView::spatialAttachments()
  -> canonical range<SpatialAttachmentRecordView>
FabricSystemRootView::hardwareDomains()
  -> canonical range<HardwareDomainRef>
FabricSystemRootView::hardwareDomainContract(HardwareDomainRef)
  -> exact closed HardwareDomainContractView
FabricSystemRootView::hardwareDomainMembers(HardwareDomainRef)
  -> canonical range<FabricHardwareDomainMemberRef>
FabricSystemRootView::effectiveHardwareDomain(
    Direct(FabricClockResetDirectOwnerRef)
      | SpatialCore(SpatialCorePhysicalDomainTargetRef),
    Clock | Reset)
  -> exact HardwareDomainRef
FabricSystemRootView::transportResources()
  -> canonical range<SystemTransportResourceRef>
FabricSystemRootView::transferPatterns(SystemTransportResourceRef)
  -> canonical range<FabricTransferPatternRef>
FabricSystemRootView::clockCrossing(SystemTransportResourceRef)
  -> optional<ClockCrossingContractView>

The unconditional closure projection is Fabric-only derived state. It evaluates each canonical handshake definition shape once, then applies the shape result through the exact occurrence or resident-row binding. Repeated rows never trigger repeated graph construction or reachability, while strict import still validates the complete root-level closure assembled from those bindings. Shape ordinals come from the normative Fabric definition relation; they are not hashes, object addresses, paths, or process-global cache keys. Selected verification starts from this immutable closure and materializes only the owner-local nodes and arcs reached by the exact typed selection. The final verifier independently rebuilds that active overlay; it does not trust a candidate's incremental graph or a diagnostic projection.

FabricHandshakeOwner is a sealed view-only union of existing occurrence-level Fabric owners and fixed point connections. HandshakeActivationFragmentOrdinal is an owner-model-local index. Neither receives a persistent reference kind or identity. HandshakeOwnerModel exposes ordered boundary signal bindings, owner-local dependency junctions, unique potential arcs, and typed activation fragments. Its internal junctions are not transport endpoints and cannot be routed, serialized, or referenced by Mapping records.

The exposed model is a logical flattened view. Its immutable structural storage is shared according to the exact Fabric-owned FU-template, Memory-Engine-template, or switch-row-shape relation, while occurrence and row bindings remain distinct. Logical node, arc, and fragment ordinals are stable within that flattened view regardless of whether the implementation shares storage. Context statistics report both logical expanded counts and unique structural counts so storage sharing cannot hide work performed by a consumer.

The selection resolver accepts only the complete typed choice owned by the resource: an occurrence-local traversal group, an FU occurrence plus one exact capability row, a memory occurrence plus one exact operation plan, or a system transfer pattern, including every selected physical refinement declared by that owner. Missing, foreign, stale, definition-only, or contradictory choices are rejected. A registered traversal break may validly resolve to no combinational fragment; it is not an endpoint-projection error.

This owner model is the only API by which Mapping, simulation, or RTL obtain resource-local ready/valid dependencies. Consumers cannot reconstruct them from operation names, latency, a generic "stateful" flag, independent UsePattern interpretation, or caller-provided arc lists. The compact owner-local graph may introduce private dependency junctions, but for every selection it must preserve the exact boundary dependency reachability implied by the normative resource equations.

Before persistent IDs exist, the finalizer invokes the same owner compiler over its private root-complete semantic view and obtains identifier-free owner models. It derives the unconditional boundary relation from those models and the declared local configuration domains. The post-ID API above is the canonical reference projection of the same equations, not a second algorithm. Private keys and junctions cannot escape finalization or be compared with persistent references.

FabricSystemRootView is a zero-copy typed refinement of the same immutable storage. It has no independent constructor or relation lists. Refinement of a non-System root is a typed wrong-root-kind error, not an empty view.

MemoryOperationPortView exposes the exact endpoint inventory, validated embedded ResourceContract, canonical ResourceState and UsePattern references, memory-specific operation-pattern semantics, and capability-alternative references. MemoryCapabilityAlternativeView exposes the OperationSchema-owned actor-contract domain, canonical service-role bindings, optional parameterized access domain, and typed admissible use-pattern references. These views are the only C++ projection of the operation-port persistent records in docs/spec-fabric-mem.md; counts, raw MLIR attributes, and consumer-owned geometry tables are not alternative APIs.

FinalizedFabricRoot is an owner result that contains the exact ArtifactRootReference, canonical bytes, direct dependency references, and sealed FabricArtifactView. It is not a new Artifact family or a second root model. There is no public freezeEntireFabricRoot API.

FabricImportBinding proves only that a compact reference is interpreted against the expected exact artifact and root kind. It neither proves relation completeness nor authorizes a caller to supplement, omit, or replace root facts. Whole-root validators consume the appropriate root view directly and must not accept shadow topology, domain, membership, or crossing catalogs.

Malformed hardware is Invalid. Any semantically complete Fabric, whether custom or expanded from a builtin template, remains a valid Fabric artifact when an RTL or EDA provider is absent. The consumer requesting that backend reports typed Unsupported. Official backend-ready qualification of a builtin requires complete provider closure, but qualification is not Fabric publication and cannot become a second Fabric identity.

Ownership Boundaries

This artifact family does not own:

• software operation semantics, owned by the canonical operation schema;
• physical sharing legality, owned by the HSG registry;
• concrete fabric.op capability, owned by Fabric operation contracts;
• backend availability or recipes, owned by Fabric-to-RTL providers;
• software-selected actor and refinement facts, owned by Mapping;
• physical configuration encoding, owned by ConfigurationABI;
• implementation realization and tool outputs, owned by HardwareImplementation; or
• timing, power, area, and other measured or predicted observations, owned by EvaluationEvidence.

Fabric itself remains the authority for resource state, capacity, use-pattern, transition-timing, and progress capability contracts. HardwareImplementation and Evaluation may realize or observe those contracts, but neither may redefine them.

These owners may reference a Fabric artifact. They may not copy its topology, capability, identity catalog, or canonicalization rules.

Implementation Responsibility Review

lib/Fabric/Artifact/FabricArtifact.cpp is the transaction composition owner for Module/System finalization and strict import. It assembles the canonical root view, runs the complete owner validation sequence, and publishes only the root that the same strict importer reconstructs. Bytecode framing, dependency closure, canonical labeling and materialization, Module view helpers, System validation, interconnect realization, configuration-field relations, and import-session caching already have independent modules and remain outside this composition owner.

The remaining Module and System paths intentionally stay together because they share one strict-import result, one dependency-resolution transaction, and one publication invariant. Splitting either path further would require a new intermediate view or pass-through protocol with no independent semantic owner. That would duplicate or disperse the strict-import authority rather than improve cohesion. The file therefore remains above the ordinary review threshold after this responsibility review; future extraction is warranted only when a new independently testable semantic owner appears.

Anchor Verification

Anchor tests cover:

• equivalent regular and irregular Fabrics with different source names and construction order producing identical bytes and identity;
• one semantic topology, capability, state, timing, or domain change producing a different identity;
• wrong-kind, foreign, duplicate, cyclic, and missing direct references;
• fixed byte vectors for every root variant, zero and multiple dependencies, dependency-table target uses, and malformed count or length framing;
• the loom.fabric.semantic.v7 envelope, Module slot/assignment relation, System occurrence-slot membership, and memory-plane spatial service binding changing identity exactly when their semantic content changes;
• strict field-owned dependency-use decoding, target re-encoding, and rejection of missing, wrong-role, wrong-target, and unused dependency rows;
• rejection of any envelope-only or dependency-preflight path that attempts to construct or return FinalizedFabricRoot before the complete finalization pipeline and strict reimport have succeeded;
• preservation of the ImplementationInput = 2 wire ordinal together with authoring, encoding, finalization, and import rejection before object lookup;
• owner-local reference kind round trips and rejection of unknown or repurposed kind ordinals;
• rejection before root publication when one exact dependency is missing or owner-invalid;
• single-object complete-or-absent root publication, independently visible dependencies, and deterministic retry after ambiguous publication failure;
• independent import and re-verification of canonical bytes;
• exact agreement between every complete relation range and its convenience queries;
• exact agreement between Module assignments plus System slot membership and the derived occurrence-qualified effective-domain range, with no serialized expanded member catalog;
• rejection of a hidden clock-domain crossing even when a caller would have omitted that point connection from a former shadow list;
• rejection of attempts to construct, subclass, or publicly freeze a partial root view;
• full expansion of a nested instance whose cross-instance connections expose an invalid unconditional cycle, plus rejection of every residual fabric.instantiate;
• rejection of a root-kind-2 generic module payload and typed FabricRootProviderUnavailable when the exact fabric.interconnect_implementation owner provider is absent;
• the 7.1 queue-discipline joints: StrictFifo and PerTagVirtualChannel round trips through finalization and strict import, rejection of per_tag_virtual_channel on an untagged or bypassable FIFO, distinct canonical identities for distinct disciplines, cold-rebuild identity stability, rejection of a 7.0 reference by the ordinary 7.1 importer, and exact 7.0-to-7.1 migration reproducing the native 7.1 identity for a Module and for a System with its recursive dependency closure;
• a valid custom Fabric with a missing backend provider reporting Unsupported; and
• a builtin target publishing with complete semantic capability while a later backend request reports typed Unsupported for missing provider closure.

Tests do not freeze one canonical-labeling implementation, MLIR printer whitespace, Builder handle order, filesystem layout, or a large topology fixture matrix.