Dependency / Impact

Assertion identity distinct from endpoint identity

A dependency assertion has weak, host-dependent identity. PROV makes the identifier on a qualified influence optional, RDF reification supplies no identity guarantee, and RDF blank node identifiers are explicitly local to a file or store and not persistent or portable; a CycloneDX bom-ref is unique only within the root bom element of one document. The assertion identifier must therefore be minted under a stated identity priority, must never be conflated with either endpoint's identifier, and where no identifier exists the assertion is reconstructed from a deterministic correlation key plus the host record that scopes it.

1. Which identifier scheme mints this assertion identifier, and is it an authoritative master-system identifier, a governed IRI or URN, or a Dimension-assigned UUID? identity
2. When no global identifier exists, which host record, document or named graph scopes the local assertion identifier? composition
3. How is the assertion identifier kept demonstrably distinct from the identifiers of the dependent and prerequisite endpoints? definition
4. Which normalization rules make two syntactically different assertion identifiers equivalent, and which differences must never be collapsed? validation

Issuer, authority basis and the three assertion times

Every assertion is attributed to an agent that speaks under some authority, and carries times that must not be conflated: declared-at (when the issuer made the claim), observed-at (when the dependency condition was seen to hold at the endpoints) and recorded-at (when the record entered this model). RFC 3339 fixes the representation but not the distinction, and SPDX carries startTime and endTime on the relationship itself, so the effective interval is a property of the claim rather than of either endpoint.

1. Which agent issued this assertion, and is that agent recorded separately from the agent that supplied the underlying observation? provenance
2. What are the declared-at, observed-at and recorded-at values for this assertion, and which of them orders competing records? temporal
3. Under what delegated authority may this issuer assert a dependency involving endpoints it does not own? authority
4. Which attribution facts must be present before an assertion may leave draft status? requirement

Governing context and applicable endpoint types

An assertion is only meaningful inside a declared context: the adopting Dimension and tenant that govern the record, an optional jurisdiction, the purpose for which the claim was made, the endpoint types the claim is declared applicable to, and any qualifier narrowing it to an environment, deployment or lifecycle phase. TOSCA requirements constrain valid target types before any relationship is admitted, and CSAF relationship categories are only interpretable against a product tree; both show that applicability must be stated rather than inferred.

1. Which adopting Dimension, tenant and jurisdiction govern this assertion record? ownership
2. Which endpoint types is this assertion declared applicable to, and what is recorded when an endpoint's type falls outside that set? classification
3. For which declared purpose was this assertion made, and may a consumer reuse it for a different purpose without re-issuance? decision
4. Which environment, deployment or lifecycle-phase qualifiers narrow the applicability of this assertion? constraint

Envelope lifecycle, revision and supersession

An assertion record moves through draft, active, superseded, retracted and expired states. PROV separates a revision from a new entity and treats disagreeing accounts as coexisting bundles rather than as an error, so this model records parallel assertions from different issuers side by side and never silently overwrites one with another. Which changes are revisions and which break identity is fixed by canonicalization rule, not decided at write time.

1. Which lifecycle states may an assertion envelope occupy, and which transitions between them are permitted? lifecycle
2. Which changes to an assertion require a new assertion identifier rather than a new revision of the existing one? decision
3. How is a retracted or superseded assertion distinguished from one that simply expired at the end of its effective interval? state
4. How are competing assertions from different issuers about the same endpoint pair carried without one overwriting another? exception

Canonical direction and role binding

The canonical direction is dependent or consumer to prerequisite or provider: the dependent is the party affected if the prerequisite is absent, changed or withdrawn. TOSCA states this explicitly for DependsOn (the prerequisite is processed first), SPDX runs from a single from element to one or more to elements, and CycloneDX dependsOn lists what the described component requires. Direction is nonetheless not universal: CSAF categories such as installed_on invert the intuitive reading, and RFC 8288 deprecated the reversed rev parameter precisely because reversed relations proved error-prone. Imported relations are therefore normalized once into the canonical direction, with the original term and its native direction preserved verbatim.

1. Which endpoint holds the dependent role and which holds the prerequisite role under the canonical direction? relationship
2. When the source vocabulary states the relation in the opposite direction, how are the original term and its native direction preserved? interoperability
3. Which typed relation term does this assertion carry, and which governed vocabulary defines its meaning? classification
4. What must be established before an imported relation is recorded as direction-reversed rather than rejected? validation

Endpoint locators, namespaces and comparison

Each role binding carries a scheme-qualified locator. RFC 3986 makes schemes a federated naming system and states that the presence of a URI implies neither access nor resolution; RFC 8141 requires URN namespaces to publish their own uniqueness and persistence rules and separates assignment from resolution. Sub-endpoints are addressed with an anchor rather than by minting a new endpoint identity, following the RFC 8288 anchor parameter and RFC 3986 fragment semantics. Because a CycloneDX bom-ref is unique only within one document, any imported document-local reference must be rebound to a scheme-qualified locator or explicitly marked host-scoped.

1. What form does each endpoint locator take, and which scheme or namespace authority governs it? identity
2. How is a sub-endpoint such as an interface, partition or component addressed without minting a new endpoint identity? composition
3. Which comparison level determines whether two endpoint references denote the same endpoint? validation
4. What must the reference carry so a consumer can resolve it, given that this model performs no resolution? interoperability

Live references, version pins and immutable snapshots

A reference is either live (tracking whatever the locator currently denotes) or pinned to a specific version, content digest or snapshot. RFC 6920 gives the content-addressed form: a self-verifying name compared on digest algorithm and value alone, which names content but does not locate it. PROV separates a general entity from its specialization and a revision from its source, which is the alignment for treating a pinned reference as a specialization of the live endpoint. A declared compatibility range states which upstream revisions the issuer claims the assertion still covers; deciding whether a new revision actually satisfies it is the endpoint owner's and the consumer's work, not this model's.

1. Is this reference live, pinned to a version, pinned to a content digest, or pinned to a snapshot? classification
2. Which digest algorithm and value bind an immutable snapshot to this reference? evidence
3. Which upstream revisions does the issuer declare compatible with this assertion, and how is that range expressed? constraint
4. What is recorded when the pinned revision is withdrawn or replaced upstream? exception

Epistemic, completeness and resolution states

Silence must never become proof. SPDX separates an explicit NoneElement (no such relationship exists) from a NoAssertionElement (no assertion is being made), and its RelationshipCompleteness vocabulary separates complete, incomplete and noAssertion. CycloneDX encodes the same distinction in the opposite way - an empty dependency element means no dependencies, while an unrepresented component means unknown - so the two encodings are not interchangeable and a normalized epistemic state must be recorded explicitly. Reference resolution adds a further axis: resolved, unresolved or dangling, ambiguous, or withdrawn upstream, each carrying a verification time and a staleness horizon.

1. Which epistemic state applies here: dependency asserted present, asserted absent, unknown, not assessed, or unresolved? state
2. Is the prerequisite set for this dependent declared exhaustive, known not to be exhaustive, or unqualified? quality
3. When was this endpoint reference last verified, and after what interval is that observation treated as stale? measurement
4. How does the record distinguish an explicitly asserted independence from the mere absence of any assertion? definition
5. Which state is recorded when a prerequisite locator resolves to more than one candidate endpoint? exception

Arity, ordering, composite prerequisites and degenerate shapes

SPDX gives one from element to one or more to elements, so one-to-one and one-to-many are native while many-to-one and many-to-many are expressed as multiple assertions sharing a prerequisite or a correlation key. TOSCA adds occurrence constraints for cardinality bounds. Ordering has no dependency-specific normative source: RDF Schema supplies rdf:Seq, where numerical ordering of membership properties is significant, and rdf:List, where ordering is structural, and these are adopted by analogy. CSAF shows that a composite of two products is given its own minted product identifier, which is why a composite prerequisite group is modelled here as a grouping over references rather than as a new endpoint. Self-dependencies, exact duplicates and reversed direction are recorded as detected shapes, never silently normalized away.

1. Which arity pattern does this assertion express, and how are many-to-one and many-to-many cases carried? composition
2. When prerequisites are ordered, what carries the ordinal and what does that order actually mean? relationship
3. How is a composite prerequisite group expressed without importing condition evaluation into this record? constraint
4. How are self-dependencies and exact-duplicate assertions detected and recorded rather than silently dropped? validation
5. Which key decides that two assertion records express the same claim? identity

Endpoint referent classes

The closed set of classes that may occupy either end of a typed dependency edge, and the rule that picks exactly one class when a candidate could be read as several. Classes span source artifacts and distributable packages or modules; source, build and test toolchain tools; deployed runtime services; interface contracts (API operations, message channels, wire protocols); data sets and data streams; schemas and ontologies; configuration items; secret and trust material referenced opaquely; compute, network and storage resources; named deployment environments; and external managed platforms outside the adopting Dimension's control. Class assignment is what makes the per-kind endpoint-type constraints enforceable, and it is deliberately independent of the storage projection: a class is a semantic role, not a document type.

1. Which referent classes may occupy an endpoint of a typed dependency edge, and what single discriminating property separates each class from its nearest neighbour? definition
2. Which identifier scheme is authoritative for each referent class, and in what order are fallbacks used when the master-system identifier is unavailable? identity
3. When a candidate endpoint reads plausibly as a package, a deployed runtime service, an interface contract and a deployment environment at once, which class wins and on what rule? classification
4. How is an endpoint recorded when it lies outside the adopting Dimension's control, such as an external managed platform, a third-party registry or a public trust anchor? access

Dependency kind register and per-kind facets

The partitioned register of typed dependency kinds together with the seven facets each kind must declare: canonical direction, permitted referent class at each endpoint, permitted cardinality, lifecycle phase or phases, version or compatibility expression rule, whether the kind licenses impact propagation, and documented false-positive exemplars. Kinds are organised by referent family - packages and modules; source, build and test toolchains; runtime services; interfaces and protocols; data sets and streams; schemas and ontologies; configuration and secret references; compute, network and storage; deployment environments; trust material; external platforms - and are required to be mutually disjoint in semantics. Representative kinds include requires-package, statically-links, dynamically-links, bundles-vendored-copy, provides-capability, built-with-tool, tested-with-tool, builds-from-source, invokes-service, conforms-to-interface, produces-to-stream, consumes-from-stream, reads-data-set, validates-against-schema, configured-by, requires-secret-reference, hosted-on, attaches-to-storage, routes-through-network, deployed-into-environment, trusts-anchor, depends-on-external-platform, conflicts-with, must-precede and co-located-with, the last being an explicit non-dependency record. No single package ecosystem's semantics are adopted globally; ecosystem-specific rules are labelled at the binding, not baked into the kind.

1. Which single registered kind code applies to this relation, and which other kinds were considered and excluded, with the reason for each exclusion? classification
2. For this kind, what is the canonical direction, which referent classes are permitted at the source and target ends, and what cardinality is allowed at each end? relationship
3. How is the kind space partitioned across referent families so that no two registered kinds share the same semantics, and what test detects an overlap? composition
4. What disqualifying conditions and documented false-positive exemplars prevent this kind from being asserted, even when a tool or manifest appears to support it? constraint
5. Which cited source or explicit Dimension decision authorises this kind, and who is accountable for changes to its facets? authority

Nature of the asserted relation

The discriminator that separates five distinct things routinely conflated under the word dependency: a functional requirement (the source cannot correctly build, start or operate without the target), a resource consumption (the source consumes capacity, quota or throughput the target supplies), a compatibility constraint (the source imposes a permissible range or shape on the target without necessarily invoking it, as with a peer relation), an ordering constraint (the target must reach a state before the source may proceed, as with a pre-dependency, without any ongoing requirement), and mere co-location or correlation (shared host, shared owner, shared release train, correlated failure timing) which is explicitly not a dependency. Nature is orthogonal to kind: two edges of the same kind may differ in nature, and nature is the primary determinant of whether an impact traversal is even meaningful.

1. Does this edge assert a functional requirement, a resource consumption, a compatibility constraint, an ordering constraint, or mere co-location or correlation? definition
2. What concretely fails, degrades or becomes unbuildable if the target is absent, incompatible, unavailable or exhausted? requirement
3. Where the edge is a resource consumption, what quantity, unit and observation basis are recorded, and are they a declared reservation or an observed draw? measurement
4. On what basis is a correlation or co-residency refused promotion to a dependency edge, and who adjudicates that refusal? decision

Lifecycle phase scoping of the edge

The phase or phases in which a dependency actually holds: design, development, build, test, deploy and runtime. Phase is the axis that SPDX 3.0.1 made explicit by defining relationships as holding 'during a LifecycleScopeType period', replacing the SPDX 2.3 practice of encoding phase into the relationship type itself (BUILD_DEPENDENCY_OF, TEST_DEPENDENCY_OF, RUNTIME_DEPENDENCY_OF). A single pair of endpoints may carry several phase-scoped edges with different qualifiers and different propagation licences: a compiler is a build-phase requirement and absent at runtime; a broker is a runtime requirement and irrelevant at build. Deploy is treated as a locally defined phase because no primary external vocabulary provides a normative value for it, and this is recorded as an open gap rather than presented as aligned.

1. In which lifecycle phase or phases does this dependency hold, and is it absent in every other phase? lifecycle
2. Does the edge hold continuously within its phase or only during a bounded window, and what start and end event times bound it? temporal
3. How does the subject's own state - not yet built, built, deployed, retired - change which phase-scoped edges a consumer should treat as active? state
4. Which external phase vocabulary value does this phase map to, and what residue remains unmapped when no external value exists? interoperability

Conditionality, alternatives and version or compatibility constraint

The qualifiers that change how a consumer must read an edge, and the grammar in which acceptable targets are expressed. Conditionality covers optional (the source proceeds without the target), peer (a compatibility expectation on a host that the source does not itself pull in), development-only, transitive versus direct, bundled or vendored (the target ships inside the source's distributed artifact), platform-provided (the target is assumed present and is not distributed), capability-satisfying (the target supplies a named capability that several providers could supply, as with a virtual package or a TOSCA capability), negative or conflicting (the target must not be present, or not at certain versions), and circular. Constraint expression covers declared ranges on an unresolved requirement versus resolved pins on a specific artifact, alternatives, and platform or engine restrictions. Grammars differ irreconcilably across ecosystems, so each expression is stored with the grammar identifier that governs its interpretation and precedence.

1. Which qualifiers apply to this edge - optional, peer, development-only, transitive, bundled or vendored, platform-provided, capability-satisfying, negative or conflicting, or circular? classification
2. How is the acceptable target version or capability range expressed, and which ecosystem grammar and precedence rules govern that expression? constraint
3. Is this a declared range against an unresolved requirement or a resolved pin against a specific artifact, and where is each of the two recorded? relationship
4. How are alternatives, negative relations and circular relations recorded so that a consumer cannot read them as ordinary requirements? exception

Edge assertion identity and validity

The dependency edge assertion is a first-class record with its own identifier, distinct from both endpoints and from any document that happens to carry it. It binds a source endpoint reference, a kind code, a target endpoint reference, a phase set, a qualifier set and the pinned kind-register version, and it carries asserter identity, event time, observation time, a validity interval and an integrity binding to the content it describes. Assertions are append-only: a correction supersedes rather than overwrites, and a withdrawal is a tombstone that preserves the identifier so a consumer can tell 'this edge was withdrawn' from 'this edge never existed'. Endpoint re-identification or re-versioning does not silently mutate an existing assertion; it produces a new one with an explicit predecessor link.

1. What identifier does the edge assertion itself carry, and how does that identifier stay stable when either endpoint is re-identified or re-versioned? identity
2. Who asserted this edge, from which artefact or system, and at what event time and separately recorded observation time? provenance
3. Over what validity interval is this edge asserted to hold, and how is a retraction distinguished from an expiry or a phase exit? temporal
4. What integrity binding ties the assertion to the endpoint content it describes, and what must a consumer do when that binding cannot be verified? validation

Determination method, evidence and completeness

How the edge came to be known and how much may be concluded from it. Three determination methods are kept strictly distinct: declared (stated in a manifest, topology declaration, interface document or other authored artefact), discovered (derived from an observation such as a lockfile resolution, a build attestation of resolved dependencies, an image inventory or a telemetry record produced elsewhere), and inferred (concluded by heuristic, similarity or model, never directly stated or observed). Each carries an evidence reference back to the producing system, a confidence statement with named limitations, and a falsification condition. Separately, completeness is asserted per subject and per kind and phase scope, because a set of edges says nothing about the edges that are missing: an empty outgoing set must never be published or read as independence, and completeness does not propagate uniformly to transitive targets.

1. Was this edge declared in an authored artefact, discovered from an observation produced elsewhere, or inferred, and which evidence reference supports it? evidence
2. What confidence and named limitations attach to a discovered or inferred edge, and what observation or statement would falsify it? quality
3. Which tool, method and version produced this determination, and is the result reproducible from the recorded inputs alone? provenance
4. How is completeness of a subject's outgoing edge set asserted for a given kind and phase scope, and how are known unknowns stated so that absence is not read as independence? validation

Declarative impact propagation licence

For each kind, a declaration of whether a downstream consumer is permitted to traverse the edge when tracing impact, in which direction relative to the edge's canonical direction, with what transitivity limit, and under what stop conditions. The distinction is deliberate: dependency direction points from dependent to dependency, whereas impact usually flows the other way, so the licence names the traversal direction explicitly rather than leaving it implicit. Stop conditions include a bundled or vendored target (impact stops at the containing artifact), a platform-provided target (impact leaves the Dimension's boundary), an optional qualifier, a negative relation, a change of referent class, a deployment-environment boundary, and any relation whose nature is co-location or correlation. The model declares and withholds permission; it never performs traversal, never computes or stores closure, and never ranks or scores what is reached.

1. Does this dependency kind license traversal for downstream impact, and in which direction relative to the edge's canonical direction? relationship
2. Is propagation transitive without limit, bounded by depth, phase or referent-class change, or forbidden outright for this kind? constraint
3. Which stop conditions terminate propagation along this kind, and what evidence must a consumer see before it applies one? decision
4. Who approves a propagation licence, and what additional evidence is required before a discovered or inferred kind is granted one? authority

External vocabulary alignment and neighbouring-analysis boundary

Bindings from local kinds, phases and qualifiers to external dependency vocabularies - SPDX relationship types and lifecycle scopes, CycloneDX dependsOn and provides with its compositions completeness assertion, TOSCA requirements and capabilities with occurrences, PROV influence and usage, package manifests and lockfiles, OpenAPI and AsyncAPI references, and infrastructure declarations - recorded with an explicit mapping strength and the residue that survives the mapping. Alignment is never conformance: a conformance claim requires published evidence. The same finding fixes the boundary against neighbouring analyses that consume or project dependency facts without being interchangeable with them: software composition analysis, vulnerability reachability, runtime call extraction and data lineage each answer a different question and are recorded as consumers or evidence producers, never as sources of typed dependency facts on equal footing.

1. Which external vocabulary term, at which vocabulary version, does this kind bind to, and is the mapping exact, broader, narrower or absent? interoperability
2. What semantics are lost or silently added when this edge is projected into a given external representation, and how is that residue recorded? constraint
3. Which neighbouring analyses are projections or consumers of dependency facts rather than sources of them, and what question does each actually answer? definition
4. What published evidence is required before conformance to an external vocabulary is claimed rather than mere alignment? quality

Process and activity reliance, and the sequence-is-not-causation rule

A process dependency asserts that an activity cannot start, continue or complete without a specific output, decision or message from another activity or participant. BPMN sequence flow orders flow elements within one process and message flow crosses participant boundaries; neither is a causal claim, and Allen interval relations order intervals without asserting causation. This finding fixes when an observed ordering may be promoted to a declared reliance and what blocking mode applies.

1. Which modelled construct grounds this reliance: an intra-process sequence flow, a cross-participant message flow, a data association, or none of these? classification
2. What specific output, decision or message does the dependent activity consume from the depended-on activity? relationship
3. If the depended-on activity does not complete, is the effect a hard stop, a degraded continuation, or a documented manual workaround? constraint
4. What evidence separates this from mere observed ordering: a modelled flow, a written procedure, or only historical co-occurrence? evidence
5. For which process version, variant or participant lane does this assertion hold? process

Capability, competence and authorisation-to-perform reliance

Reliance on an ability to perform rather than on a named holder: a capability concept, a skill or competence, a qualification, or an authorisation or licence that permits performance. ESCO supplies governed occupation, skill and knowledge concepts mapped to ISCO, so the endpoint is a concept identifier rather than free text. Regulatory function tests such as the DORA critical-or-important-function materiality test show that the dependent side is often a function, not a system.

1. Is the depended-on endpoint a capability concept, a qualification, or an authorisation to perform, and how is each defined here? definition
2. Which governed classification concept identifies the capability or competence, and at which scheme version? identity
3. What minimum proficiency, coverage or number of qualified holders must exist for the dependent function to remain performable? requirement
4. Is the dependent endpoint classified as a critical or important function under a cited regulatory test, and which test is applied? classification
5. What substitution, delegation or temporary derogation is recognised when the capability is unavailable, and what does it not cover? exception

Organizational, post and role reliance separated from ownership and reporting

W3C ORG models subOrganizationOf, hasUnit, reportsTo, Post, Role and time-bounded Membership; GLEIF Level 2 models direct and ultimate accounting consolidating parents. None of these is a dependency: a parent may supply nothing, and an unrelated supplier may be indispensable. This finding declares the reliance edge on an actor at a stated granularity and holds the tests that keep it distinct from control, ownership and reporting structure.

1. Which identifier identifies the depended-on actor: a legal entity identifier, an internal organizational unit identifier, or a post identifier? identity
2. Is the asserted edge a reliance on the actor's performance, or a structural, ownership or reporting relation already mastered elsewhere? relationship
3. At what granularity is the reliance asserted: legal entity, organizational unit, post, or the individual holder of a post? composition
4. Who owns the depended-on actor record, and does a change of ownership or consolidation alter the reliance claim? ownership
5. How is the reliance re-evaluated when the post is vacant, the unit is merged, or the holder changes? lifecycle

Supplier, third-party and subcontracting-chain reliance

Reliance on external parties, distinguishing outsourcing of a function from purchase of goods or services and from informal reliance, recording chain position for direct and indirect partners and nth-tier subcontractors, and capturing substitutability as an assessment input. Scope differs by instrument: a CSDDD chain of activities excludes product disposal and, for regulated financial undertakings, downstream activities, while a DORA register of information covers ICT arrangements including subcontracting; the same counterparty can therefore be in one scope and outside another.

1. Is the arrangement outsourcing of a function, a purchase of goods or services, or a reliance with no contract at all? classification
2. What is the depended-on party's chain position, direct partner, indirect partner or nth-tier subcontractor, and through which intermediate parties? composition
3. How substitutable is the party, measured on what scale, and over what switching period? measurement
4. Which external register or reporting schema must this record populate, and what mandatory fields does that schema impose? interoperability
5. Which contractual right or supervisory power permits visibility into the sub-tier, and where does that right end? authority

Normative obligation distinguished from operational reliance

An obligation is a deontic statement: a duty owed by or to a party under a contract, statute or policy, with an assigner, an assignee and a fulfilment condition. Operational reliance is a factual statement that performance fails without a counterparty's act. They frequently co-occur but are independent: a redundant duty can exist with no reliance, and an informal accommodation can create reliance with no duty. This finding carries only the citation, the deontic class asserted at the source, and the outcome of the independence test; the rule's text, remedies and fulfilment state stay with the instrument model.

1. Is the asserted item a duty, a condition attached to a permission or prohibition, or a purely factual operational reliance? definition
2. Which legal act, contract clause or policy statement is cited, by governed identifier and version? provenance
3. Which party bears the duty and which benefits, and does that direction match the direction of the operational reliance? authority
4. What consequence does the cited rule attach to non-performance, and is that consequence recorded here or owned by the instrument model? constraint
5. What test shows whether removing the obligation would remove the operational reliance? validation

Financial and non-financial resource reliance

Reliance on funding, revenue concentration, payment settlement, workforce capacity or material resources. The UN/CEFACT Buy-Ship-Pay model separates the buy, ship and pay strands, so reliance on a counterparty for settlement is a different assertion from reliance on the same counterparty for delivery or for the underlying agreement. Business impact analysis practice supplies the resource-requirement framing. Accounting recognition and any payment execution are excluded.

1. Which resource strand is relied upon: funding or budget, revenue, payment settlement, workforce capacity, or physical material? classification
2. What quantity, share or concentration figure expresses the reliance, in which unit and over which period? measurement
3. Does the reliance run to a named counterparty, to a specific instrument or facility, or to an aggregate pool? relationship
4. What resource state does the reliance assume: committed, contingent, discretionary, or withdrawn? state
5. Which contingency, reserve or alternative source is recognised, and what does it explicitly not cover? exception

Temporal, spatial and jurisdictional reliance

Three situational kinds. Temporal reliance binds the subject to a window, deadline, calendar or required lead time, expressed with Allen interval relations for topology and RFC 3339 instants for endpoints. Spatial reliance binds it to a site, access route or co-location using governed location codes. Jurisdictional reliance binds it to an authorisation, recognition or applicable-law condition of a named jurisdiction, cited by governed legal identifier. DORA's specific concern with subcontractors established in a third country is an example that jurisdictional reliance is material; it is used as an instance, not as universal doctrine.

1. What temporal relation is asserted between which two intervals, and is a minimum lead time required? temporal
2. Which governed location or site identifier bounds the reliance, and does the reliance survive relocation of that site? spatial
3. Is the jurisdictional element an authorisation to operate, a recognition or equivalence, a localisation constraint, or a choice of governing law? classification
4. What becomes of the assertion when the window closes, the site becomes unavailable, or the authorisation lapses? state
5. Which code lists are used for country, subdivision and location, and at which versions? interoperability

Direction, endpoint constraints, cardinality and applicability per kind

Every kind in the taxonomy declares its permitted dependent and depended-on endpoint types, its canonical direction, whether an inverse is derived rather than stored, cardinality on each side, whether cycles are permitted, whether the relation is transitive across chain hops, and the conditions under which the assertion applies at all. The specialization pattern of a non-causal influence superproperty supplies the modelling idiom, the withdrawal of the reportsTo acyclicity claim shows that cycle behaviour must be declared and not assumed, and the sequence-versus-message distinction shows that endpoint scope differs by kind.

1. For this kind, which dependent and depended-on endpoint types are permitted, and which are explicitly forbidden? composition
2. What cardinality applies on each side of this kind, and is a cycle permitted? constraint
3. Is this kind transitive across chain hops, and if not, how must multi-hop reliance be declared? relationship
4. Which conditions must hold for an assertion of this kind to be applicable, and what renders it inapplicable? requirement
5. Which external property or definition does this kind align to, and at exactly which point does the alignment stop? interoperability

Evidence basis, discrimination tests and false-positive disposition

Every declared dependency records its basis (modelled artefact, written agreement, cited legal act, interview, observed telemetry, statistical association), an evidence grade, an asserting agent possibly acting on behalf of another, and an assertion time held separately from the observation time. It also records the outcomes of four discrimination tests: ownership is not dependency, sequence is not causation, correlation is not a declared dependency, and obligation is not reliance. Assertions supported only by association are downgraded to candidate rather than published. Refutation is a disposition on the assertion, retained rather than deleted. This model records the disposition and emits attribution entries; the enforcement, risk-scoring and audit-trail engines that consume them are owned elsewhere.

1. What is the basis of this assertion, and what evidence grade does that basis carry? evidence
2. Who asserted the dependency, on whose behalf, and at what assertion time as distinct from the observation time? provenance
3. Which discrimination tests were run for ownership, sequence, correlation and obligation, and what were their outcomes? validation
4. What observation would falsify this dependency, and has that check actually been performed? quality
5. What review interval or trigger applies, and how is a refuted assertion dispositioned without deleting it? lifecycle

Condition identity, canonical direction, endpoints, typed kind and lifecycle scope

A dependency condition is an addressable assertion in its own right, not a property of either endpoint. Its source endpoint is always the dependent and its target is always the prerequisite, matching the SPDX from-to orientation and the CycloneDX ref-to-dependsOn orientation. Some vocabularies declare from the prerequisite side (Debian Enhances, RPM Supplements and Enhances) or use inverse relationship names, so a recorded normalization step is required before the condition can be read in canonical form. The typed kind additionally carries provisioning meaning that must not be confused with strength: SPDX hasProvidedDependency marks a dependency assumed to be provided rather than distributed, and static versus dynamic linkage is a typing distinction, not a strength distinction. The lifecycle scope (build, design, development, runtime, test, other) bounds where the condition applies at all, and a scope-bounded condition is not an unconditional edge.

1. What stable identifier addresses this dependency condition itself, independently of the two endpoints it connects? identity
2. Which endpoint is the dependent and which is the prerequisite under the canonical dependent-to-prerequisite direction? relationship
3. Was the condition originally expressed in a reverse, prerequisite-side or inverse-named form, and what normalization was applied? provenance
4. Which typed dependency kind classifies this condition, and does that kind carry provisioning or linkage meaning that must not be read as strength? classification
5. In which lifecycle phases does this condition apply, and is it inapplicable outside them? lifecycle

Obligation level, optionality encoding and preference weight

Strength is expressed in at least three incompatible ways across authorities: as a distinct relationship type (SPDX dependsOn versus hasOptionalDependency), as a distinct field with graded meaning (Debian Pre-Depends, Depends, Recommends, Suggests; RPM Requires, Recommends, Suggests), and as a cardinality lower bound of zero (TOSCA count range). Kubernetes adds a fourth encoding in which hard rules block the operation and soft rules carry a weight from 1 to 100 that is summed during scoring. RFC 2119 supplies a domain-neutral three-level scale in which SHOULD explicitly admits justified departure. The model therefore records one normalized obligation level plus the native encoding, and refuses to assert a single total order across scales, because an ordinal field grade and a cardinal scheduling weight are not commensurable.

1. What normalized obligation level does this condition carry: absolute requirement, recommended, optional or informational? requirement
2. Is optionality encoded as a separate relationship type, a separate field name, or a cardinality lower bound of zero? classification
3. If the condition is soft, what preference weight or rank is declared and on what scale is it defined? measurement
4. What non-binding statement of consequence for the dependent accompanies the condition in its source vocabulary? decision
5. Which strength distinctions are lost when this condition is projected into a target vocabulary that has no strength axis? interoperability

Ordered prerequisites and the ordering-versus-existence distinction

Ordering is a separate axis from existence. The systemd unit model states that ordering settings are independent of and orthogonal to requirement dependencies, so a unit can require another without ordering against it, and can order against a unit it does not require. Debian Pre-Depends instead couples the two, requiring the prerequisite to be fully installed before the dependent's installation starts, with staged acceptance criteria that differ between unpack and configure and an explicit prohibition on circular pre-dependencies. Requisite adds a further distinction: the prerequisite must already be in the required state and will not be brought into it as part of satisfying the condition. The model therefore records the ordering assertion, the required prerequisite state, the stage boundary being gated, and whether pre-existence is demanded, without computing any sequence.

1. Does this condition assert ordering, existence, or both as separately recorded assertions? relationship
2. Which state must the prerequisite have reached before the dependent may proceed past the gated stage? state
3. Must the prerequisite already be in the required state, or may it be brought into that state as part of satisfying the condition? constraint
4. Are circular ordered prerequisites permitted for this condition, and how is a declared cycle recorded rather than resolved? validation

Alternative sets, cardinality bounds and n-of-m satisfaction thresholds

A single condition may be satisfiable by any of several targets. Debian expresses this with the pipe operator and treats the listed order as meaningful, with autobuilders discarding architecture-mismatched options and taking the first remaining name. RPM expresses it with or, and adds with, which requires all operands to be satisfied by the same package, and without, which requires a package satisfying the first operand but not the second. TOSCA expresses multiplicity as a count range, so the satisfaction threshold is a bounded interval rather than a boolean. Kubernetes allows several soft rules to contribute weights independently, which is a scored rather than a thresholded form. The model records the member set, the threshold, whether members must bind to the same target, and whether any preference order is normative or conventional.

1. Which candidate targets form the alternative set able to satisfy this single condition? composition
2. How many members must hold for the condition to count as satisfied, and is the threshold a minimum, an exact count or a bounded range? constraint
3. Is a preference order declared among alternatives, and is that order normative or merely conventional? decision
4. Must the satisfying members be provided by one and the same target, or may satisfaction be spread across several targets? constraint

Guards, applicability predicates and the inapplicable-versus-failed distinction

A guarded condition holds only when its guard is true, and a false guard makes the condition inapplicable rather than unsatisfied. RPM makes this explicit with if, if-else, unless and unless-else, and constrains their combination so that if cannot appear with or and unless cannot appear with and. Debian restricts relationships by architecture in square brackets, with negation, and by build profile in angle brackets interpreted as disjunctive normal form. systemd separates Condition directives, where an unmet condition causes the unit start to be mostly silently skipped without entering a failed state, from Assert directives, where failure is an error. Kubernetes scopes matching to scheduling and ignores it during execution, so guard evaluation timing is itself part of the declaration. The critical compositional rule is that a guarded condition must never be flattened into an unconditional edge in any projection.

1. Under what declared guard predicate does this condition become applicable at all? constraint
2. When the guard is false, is the condition inapplicable and silently skipped, or is falsity itself a failure? exception
3. Is the guard tied to a single stage boundary or continuously applicable, and does a later change reopen applicability? temporal
4. Can the guard survive projection into the target vocabulary, and what must be refused if it cannot? interoperability

Comparison predicates, compatibility ranges and quantitative thresholds

Conditions are frequently expressed against a value rather than a bare existence test. Debian defines the version relations strictly earlier, earlier or equal, exactly equal, later or equal and strictly later. The OSV schema shows that a range is only interpretable under a declared ordering scheme: semantic-version precedence, uninterpreted ecosystem strings that need an explicit enumerated version list, or a commit graph that must be consulted; and it fixes the half-open reading in which the fixing endpoint is excluded. Kubernetes supplies set and existence operators and warns that its greater-than and less-than comparisons are lexicographic on label values. TOSCA constrains target selection through node filters over property constraints. The model therefore records the operator, the operands, the endpoint inclusivity, the ordering scheme reference and, for quantitative thresholds, the unit and measurement basis; it never performs the comparison.

1. Which comparison or membership operator and which operands define the acceptable prerequisite values? constraint
2. Which ordering or comparison scheme makes the operands comparable, and is that ordering total? measurement
3. Are the interval endpoints inclusive or exclusive, and is the range half-open? definition
4. For a quantitative threshold, what unit, precision and measurement basis apply to the operand? quality
5. When the ordering scheme is undefined for the operands, what enumerated value set stands in for the range? interoperability

Negative conditions and declared incompatibilities

Not all dependency conditions are positive. Debian defines Conflicts, which prevents two packages from being unpacked simultaneously, and Breaks, which prevents configuration of a broken package while the breaking package is unpacked, alongside Replaces. RPM permits boolean expressions in Conflicts and provides unless and without as negative forms, and states that Provides may not carry boolean expressions. systemd defines Conflicts as a negative requirement in which starting one unit stops the other, and Kubernetes uses NotIn and DoesNotExist to express anti-affinity. A negative condition is therefore a first-class declaration with the same identity, direction, scope and strength machinery as a positive one, and two declarations can be mutually contradictory as authored. This finding records exclusions and asserted contradictions; it does not detect, rank or resolve them.

1. Is this condition positive, requiring presence, or negative, requiring absence or non-coexistence? classification
2. At which stage or state does the exclusion bite, and does it forbid coexistence or only a particular transition? state
3. Which other declared conditions are asserted to be mutually contradictory with this one, and who asserted that? validation
4. Is the declared condition set recorded as unsatisfiable as authored, without any attempt to resolve it? evidence

Declared condition versus recorded satisfaction, violation, inapplicability, unknown state and deviation

The declared condition and any statement about its satisfaction are different objects with different provenance and different time bases. Following the SHACL separation, this model carries a status snapshot and a reference to the externally produced result, never the evaluation itself: conformance in SHACL is defined as an empty result set with no reported failure, and the report is produced by a processor. The status vocabulary must distinguish satisfied, violated, not-applicable (the guard was false, which systemd treats as a silent skip rather than a failure) and unknown, since silence is not satisfaction. Severity is a declared qualifier of a result, as in the SHACL Violation, Warning and Info scale, and is not the same as the condition's obligation level. A deviation, whether a waiver, a concession or a declared deactivation in the sense of a shape that is switched off while remaining defined, is recorded as a reference to a decision owned elsewhere, together with its subject binding and declared validity window, on the requirement-level principle that departure from a recommended item demands that its implications be understood and weighed.

1. What is the last recorded satisfaction status of this condition, and does the vocabulary separate unknown from not-applicable? state
2. Which external evaluator produced the result, and where is the full result retained? provenance
3. What are the event time of the observed state change and the separate observation or ingestion time of this record? temporal
4. Is a waiver, concession or deactivation recorded against this condition, and which decision record authorises it? exception
5. Which model owns the approval, verification and retention of the deviation decision referenced here? authority

Completeness assertion, open-world default and the reading of absence

A set of declared conditions is not a closed world unless someone says so. SPDX makes this explicit with complete, incomplete and noAssertion, meaning the relationship is known to be exhaustive, known not to be exhaustive, or carries no claim. CycloneDX makes the operational consequence explicit: a component with no dependencies must be declared as an empty element, whereas a component absent from the graph may have unknown dependencies and should be treated as opaque rather than dependency-free. OWL 2 states the underlying epistemics, that a fact absent from a document may simply be missing but possibly true. The model therefore defaults to the open-world reading, requires an explicit empty declaration to assert that a subject genuinely has no conditions of a given kind, and treats completeness as an attributed, scoped assertion with its own provenance rather than as an inferred property.

1. For this subject and scope, is the declared condition set asserted to be exhaustive, non-exhaustive, or is no claim made? evidence
2. How must the absence of a condition be read: as no condition, as an unknown condition, or as out of scope? definition
3. When a negative condition is declared, is it a classical assertion of absence or an artefact of failure to find evidence? validation
4. Which earlier completeness assertion does this one supersede, and over what scope does the supersession run? provenance
5. How long must a superseded completeness assertion be retained, and who owns that retention rule? retention

Epistemic mode and evidentiary force of a dependency claim

Classifies how a dependency or impact claim was established - declared in a manifest or by a supplier, discovered by static inspection of source or binaries, observed in a running or instrumented system, inferred by similarity or heuristic, or attested by a signed third-party statement - and fixes that each mode carries different evidentiary force. CycloneDX separates manifest-analysis from binary-analysis, instrumentation, dynamic-analysis, ast-fingerprint, hash-comparison and attestation; SPDX names DEPENDENCY_OF specifically for dependencies explicitly stated in machine-readable files; RFC 9334 separates Evidence from Endorsements; PROV separates direct-knowledge sources (hadPrimarySource) from derivations. The mode is recorded, never re-derived, and never used here to decide which of several claims is correct.

1. Which epistemic mode established this dependency claim - declared, discovered, observed, inferred or attested? classification
2. What evidentiary force does the recorded mode carry, and which modes must never be silently merged into one edge claim? constraint
3. How is an edge supported by several modes at once represented without collapsing their distinct force? composition
4. When the mode is inferred or restated, which prior claim or source claim was it derived from? provenance
5. Does this record assert direct knowledge of the dependency or a secondary restatement of another party's assertion? evidence

Discovery method, procedure and tool identification

Identifies the reusable procedure that produced a claim by reference to a registered, versioned method profile: analysis technique class, tool identity and version, configuration or rule-set version, reference-data version, and the method's declared blind spots. This mirrors sosa:usedProcedure (a described, reusable procedure rather than an executing system), the CycloneDX technique and tools structure, and the DQV notion of a metric as a defined procedure. The profile is descriptive metadata; this partition never executes, schedules or configures a detector.

1. Which registered method profile and version produced this claim? identity
2. Which analysis technique class does the method belong to and what are its documented blind spots? quality
3. What rule-set, signature database or reference-data version was in force when the method ran? provenance
4. Which changes to a method profile require existing claims to be re-derived rather than merely reinterpreted? lifecycle

Asserting agent, role and authority basis

Records the accountable agent for a claim, its role in the evidence chain and the basis of its authority. PROV-O supplies wasAttributedTo and qualifiedAttribution; RFC 9334 distinguishes Attester (produces Evidence), Endorser (vouches for capability), Reference Value Provider and Verifier; OpenVEX requires an author and permits a role and supplier; CISA lists the author of SBOM data as a required attribute. The agent record distinguishes the party that observed from the party that published, and names the authority basis (supplier of record, delegated, self-asserted, third-party). Signature verification and trust decisions about the agent are external.

1. Which agent is accountable for this claim and in what role within the evidence chain? ownership
2. On what authority basis is the claim made - supplier of record, delegated authority, self-assertion or third-party assertion? authority
3. Which signed envelope or attestation carries this claim, and where is its signature verified? security
4. How are the agent that observed and the agent that published the claim kept distinguishable? provenance

Evidence source locator, fragment selector and payload exclusion

Binds a claim to the specific external evidence that supports it: a resolvable locator, a content digest that pins the exact revision, a fragment selector (file path, line, byte offset, symbol, call-stack frame, statement identifier), the media type, and any retrieval constraint. In-toto matches subjects purely by digest; CycloneDX occurrences carry location, line, offset and symbol; OpenVEX documents carry an IRI @id. The invariant is that no payload bytes, extracted secrets or excerpt text beyond a minimal locating selector are copied into this model, and that a broken or mismatched reference degrades the claim's resolvability without rewriting history.

1. How is the supporting evidence located again later, and which identifier pins the exact revision that was seen? identity
2. Which fragment of the evidence actually supports the claim? evidence
3. What must never be copied out of the evidence payload into this model? privacy
4. What happens to a claim when its evidence reference becomes unresolvable or its digest no longer matches? exception

Confidence, uncertainty, applicable scope and reproducibility conditions

Captures the strength a producer asserted and the conditions that bound it. CycloneDX carries a confidence value on an identity conclusion and on each contributing method; VIM defines measurement uncertainty as a non-negative parameter characterising the dispersion of values attributed to a measurand based on the information used, and distinguishes repeatability from reproducibility conditions; DQV structures a measurement as a value against a defined metric. This finding requires the scale to be named and versioned, the conditions under which the result was obtained to be stated, the applicability envelope (platform, build profile, configuration, population) to be declared, and comparability across methods to be governed by an explicit rule. It records these values; it never computes a score, threshold or verdict.

1. On which named scale is confidence expressed and what exactly does its value denote? measurement
2. Under which repeatability, intermediate precision or reproducibility conditions was the result obtained? quality
3. To which configurations, platforms or build profiles does this claim apply, and where does it stop applying? constraint
4. May confidence values produced by different methods be compared or aggregated, and under what recorded rule? interoperability
5. What remains unknowable from this method even at its maximum stated confidence? evidence

Observation event, subject binding and environment

Records the discrete act that produced a claim, following the SOSA pattern of an Observation carried out by a procedure on a feature of interest. Here the feature of interest is the dependency edge or the artifact under inspection, referenced - never redefined - through the core partition and external endpoint registries. The record captures the environment instance in which the observation was made (build run, deployment, target environment, as RFC 9334 separates Target from Attesting Environment), the run grouping that keeps sibling claims from one execution linked, and whether the whole population or a sample was inspected.

1. Which dependency edge or endpoint was the subject of this observation, and how is that subject referenced? relationship
2. In which environment instance, build run or deployment was the observation made? event
3. Was the whole population inspected or only a sample, and how was that sample selected? measurement
4. Which observation run does this record belong to so that all claims from one execution stay linked? identity

Time model and freshness inputs

Keeps four kinds of time distinct: the time the asserted dependency relation actually held (SPDX 3.0.1 relationship startTime and endTime; SOSA phenomenonTime), the time the observation completed (SOSA resultTime), the time the claim was recorded in this model (ingestion), and the declared validity boundary after which the claim should be re-observed. It also records which freshness mechanism demonstrates recency of the underlying evidence - signed timestamp, nonce or epoch identifier, as enumerated by RFC 9334 - and notes RFC 9334's warning that claim values may have been generated long before they were signed. This finding supplies freshness inputs; whether a claim is too stale to rely on is decided by an external appraisal or policy service.

1. When did the asserted dependency relation actually hold, as distinct from when it was observed? temporal
2. When was the observation completed and when was the resulting claim recorded here? provenance
3. For how long does this claim remain assertable before it must be re-observed? state
4. By which mechanism is the recency of the underlying evidence demonstrated - signed timestamp, nonce or epoch identifier? validation

Completeness declarations and known unknowns

Requires an explicit statement of whether an enumerated dependency set for a stated scope is exhaustive, known to be partial, or not asserted at all. SPDX 3.0.1 defines completeness as complete, incomplete or noAssertion, and distinguishes a NoneElement target (asserting no relationships exist) from a NoAssertionElement target (no assertion made); CycloneDX compositions carry an aggregate value including unknown and not-specified; CISA requires SBOM authors to identify known unknowns explicitly where the full dependency graph is not enumerated, and sets depth expectations from direct dependencies upward. The governing rule adopted here is that a missing completeness statement is read as incomplete, never as complete.

1. Is the enumerated dependency set for this scope exhaustive, known to be partial, or not asserted at all? classification
2. How is 'this node has no further dependencies' distinguished from 'its dependencies are unknown'? definition
3. Which scope does the completeness statement cover - direct dependencies only, a stated depth, or the transitive closure? composition
4. What is the default interpretation when no completeness statement is present at all? constraint

Contradiction registration, supersession and retraction

Governs the states a claim can occupy after assertion. Contradiction is registered as a pairwise relation between claims about the same edge whose scopes overlap but whose content disagrees; supersession follows the OpenVEX pattern where a later statement from the same authority overrides and enriches an earlier one; retraction follows PROV invalidation (wasInvalidatedBy, invalidatedAtTime), leaving the retracted record inspectable rather than deleted, with a required reason in the spirit of OpenVEX's mandatory justification. This partition registers and routes these states; it never decides which contradictory claim is true, and per RFC 9334 that appraisal belongs to the Verifier or an equivalent external adjudicator.

1. When are two claims about the same edge genuinely contradictory rather than merely different in scope or time? definition
2. Which claim supersedes which, and on what recorded basis does that ordering hold? lifecycle
3. How is a retraction recorded so that the retracted claim remains inspectable afterwards? retention
4. Who may retract or supersede a claim, and what reason must accompany the action? authority
5. Where is a registered contradiction sent for resolution, given that this partition does not adjudicate truth? decision

Registration lifecycle state vocabulary

A governed, versioned set of registration states for a single dependency assertion - proposed, in-review, active, deprecated, superseded, retired - with, for each, a definition, whether it is terminal, and whether an assertion in that state may be relied on for downstream decisions. This is the assertion's administrative status only; it says nothing about whether the dependency is currently being met and nothing about the endpoints' own operational state.

1. Which registration states may a dependency assertion hold, and which of them are terminal? lifecycle
2. What does each state assert about whether the dependency may be relied on for a downstream decision? definition
3. Which registration authority or role may place an assertion into each state? authority
4. Which version of the state vocabulary governs a given assertion record, and how is a retired term still resolved? interoperability

Permitted transitions, guards and transition events

The explicit matrix of allowed state pairs, the preconditions declared for each move, the justification and evidence that must accompany a transition request, and the transition event record naming requester, approver and event time. Guards are declared here in a checkable form; their runtime evaluation and any enforcement action are performed by an external rule or workflow engine.

1. Which state transitions are permitted, and which state pairs are explicitly forbidden? constraint
2. What preconditions and supporting evidence must be declared before a transition may be requested? requirement
3. What is recorded when a transition occurs, and who requested it as against who approved it? event
4. How is a rejected, withdrawn or expired proposal represented without deleting the proposal record? exception
5. Which external component evaluates the declared guards at request time, and what does it return? process

Weak, host-dependent assertion identity

A dependency assertion has no independent global identity. It is keyed relative to the host record that carries the mixin, together with the dependent and provider endpoint references, the dependency type and any lifecycle scope. Identity survives changes of registration state, condition value and effective interval, all of which are qualifiers of a record version rather than components of the key. Dates and timestamps are never key components.

1. Which attributes compose the identity key of a dependency assertion within its host record? identity
2. Does a change of registration state, condition or effective interval create a new assertion or a new record version of the same assertion? lifecycle
3. How is an assertion identified when the host record is itself versioned, replaced or merged? composition
4. What surrogate identifier may the adopting Dimension assign, and what precedence does it have against an authoritative master-system identifier? provenance

Deprecation, supersession chains and historical state

How an assertion that is discouraged but still true is distinguished from one that is no longer asserted at all, how a successor assertion is linked to its predecessor, how chains are traversed and kept acyclic, and why retired assertions remain readable instead of being erased. Reuse of a retired assertion key is treated as an interoperability hazard.

1. Which successor assertion replaces a superseded one, and is the replacement total or partial? relationship
2. How far back may a supersession chain be traversed, and how are cycles detected and prevented? constraint
3. What distinguishes deprecation, where the dependency is discouraged but still holds, from retirement, where it is no longer asserted? classification
4. Under what conditions, if any, may a retired assertion key be reused for a different dependency? decision

Externally owned endpoint state referenced, not maintained

The dependent and provider endpoints each have their own administrative state, governing whether use is permitted, and operational state, governing whether the resource is operable. Both are attributes of the managed entity and are owned by its master system. This model holds a reference to the owning system, optionally a copied state snapshot, and the instant that snapshot was read, so that a condition determination can be explained later. It never transitions endpoint state, never polls for it, and never treats a copied snapshot as authoritative after its read time.

1. Which system is the authoritative owner of each endpoint's administrative and operational state? ownership
2. Which endpoint state value was used when a condition was determined, and when was that value read? provenance
3. How does an assertion behave when a referenced endpoint is decommissioned or its state becomes unknown? exception
4. What actions on endpoint state are explicitly forbidden to this model? constraint

Condition values: satisfied, degraded, broken, restored, undetermined

A controlled vocabulary describing whether the asserted dependency is currently met, partially met, unmet, has returned to met after being unmet, or cannot be determined, together with the declared criteria that map referenced evidence to each value and the severity ordering between them. Condition is a derived property of the assertion, distinct from the assertion's registration state and from any endpoint's operational state.

1. Which condition values may a dependency assertion carry, and how are they ordered by severity? classification
2. What declared criteria map referenced evidence to each condition value, including the threshold separating degraded from broken? measurement
3. Who or what determined the condition value, and was the determination automated or asserted by a person? authority
4. How is restoration distinguished in the record from a dependency that was never broken? state
5. What is recorded when the condition cannot be determined from available evidence? quality

Health observations referenced as evidence

Observations about endpoint or dependency health are produced, stored and quality-assured elsewhere. This finding governs which observations were used as evidence for a determination and how their two times are carried: the phenomenon time to which the result applies, and the result time at which the result became available. Observations that arrive out of order are linked to the determination they should have informed without altering determinations already made.

1. Which observations were used as evidence for this condition determination, and where are they held? evidence
2. What is the phenomenon time of each referenced observation, and when did its result become available to this model? temporal
3. How is an observation whose result arrives after a later determination linked to the determination it should have informed? provenance
4. What quality or reliability qualifiers must accompany referenced observation evidence? quality
5. Which model owns collection, sampling, procedure definition and storage of these observations? interoperability

Effective intervals of assertions and conditions

Each assertion and each condition determination carries an effective interval with an inclusive start and an exclusive end, left open where it remains current, optionally narrowed to a lifecycle scope such as build or runtime. Intervals are qualifiers of a record version, never components of identity; successive intervals for the same assertion and the same time dimension must not overlap, and closing an interval is an append, not an edit.

1. What are the effective start and end of this assertion, and is the interval still open? temporal
2. Which interval boundary convention applies, and may two intervals for the same assertion overlap? constraint
3. To which lifecycle scope does the effective interval apply, given that a dependency may hold at build time but not at run time? classification
4. How is an interval closed when the assertion stops holding, without deleting or editing the earlier record? lifecycle

As-of reconstruction, late observation and correction without rewriting history

Two independent time dimensions - the effective interval over which a fact holds and the record interval over which it was believed - allow a consumer to ask what was asserted as of a chosen pair of times. A change in the world extends the effective dimension; a mistake is corrected by appending a new record version that closes the record interval of the erroneous version and, where the earlier statement was never true, annuls it with an explicit reason. Prior record versions are immutable so that a citation to a past state stays stable.

1. Which pair of times must a consumer supply to reconstruct the assertion set as of a chosen moment? temporal
2. How is a correction of a mistaken record distinguished from a genuine change in the world? decision
3. What is recorded when an earlier assertion is annulled as never having been true? validation
4. How is a prior record version addressed so that a downstream citation remains stable and resolvable? provenance
5. Who may issue a correction or annulment, and what evidence must accompany it? authority

Asserted dependency edge as a primary fact

An asserted edge is a first-class, addressable statement that a source subject depends on one or more target subjects under a named relation type, a lifecycle scope, a validity interval, an asserting agent and a confidence value. It is treated as immutable: corrections are made by superseding assertions, never by silent edit, so that any projection computed over an earlier edge set remains explainable. Endpoints are references into an owning inventory model, never copies of the entities.

1. What identifier makes this asserted dependency edge addressable independently of its endpoints? identity
2. Which typed relation does the edge assert, in which direction, and under which lifecycle scope? classification
3. Over which validity interval is the asserted edge held to be true, and when was that observed? temporal
4. Who or what asserted the edge, from which evidence, and with what confidence? provenance
5. How do the edge endpoints resolve to entities owned by an external inventory model? interoperability

Direct, transitive, inferred and hypothetical modality

Every dependency statement carries a modality discriminator plus, for non-direct modalities, the basis that licensed it. Direct means asserted by an agent about an immediate relation. Transitive means produced by composing asserted edges under a declared closure with a stated depth bound. Inferred means entailed by a declared property characteristic, property chain or rule. Hypothetical means postulated for what-if analysis and not claimed to hold. PROV-CONSTRAINTS establishes that derivation is not transitive by default, and RDF 1.1 Semantics establishes that a valid inference need not be materialised, so both transitivity and materialisation must be declared rather than assumed.

1. How are direct, transitive, inferred and hypothetical relations defined so that they never collapse into one another? definition
2. For an inferred or transitive relation, which rule, property characteristic or closure method licensed it? relationship
3. Is a derived relation materialised as a stored statement, and how is it kept distinguishable from asserted facts? state
4. Under what conditions may a hypothetical relation enter an impact answer, and how is that answer labelled? decision

Conditions under which an edge licenses propagation

An edge is a fact; it is not automatically a channel for impact. A propagation licence profile states which combinations of relation type, lifecycle scope, direction, validity overlap and minimum confidence permit traversal for a given impact question. Because SPDX records that a build dependency carries different implications from an operational dependency, the same asserted edge can license propagation in one scope and not in another. The default is deny: an edge that matches no profile is not traversed, and the resulting answer says so rather than silently omitting a branch.

1. Which combination of relation type, lifecycle scope and direction licenses impact to propagate along an edge? constraint
2. What is the default when no propagation licence profile matches an edge? requirement
3. What minimum assertion confidence must an edge carry before it may be traversed for a published impact answer? measurement
4. How must an edge validity window overlap the analysis reference time for traversal to be permitted? temporal
5. Who owns and versions a propagation licence profile, and how are competing profiles resolved? authority

Typed exclusion of a present edge

An edge that exists and matches a licence profile may still be excluded from a specific impact answer for a stated, evidenced reason. OpenVEX demonstrates the pattern with machine-readable justifications such as the vulnerable code not being present, not being on the execute path, not being controllable by an adversary, or being covered by inline mitigations. Generalised here, an exclusion is a typed, scoped, expiring statement over an edge, an edge class or a subgraph. The critical rule is reporting: an excluded edge must be visible in the result as suppressed, never rendered as absent, because absence carries a completeness claim that an exclusion does not.

1. Which machine-readable justification explains why a present edge does not propagate impact in this case? exception
2. What is the applicability scope of an exclusion and when does it lapse? temporal
3. What evidence supports the exclusion and who reviewed it? evidence
4. How is an excluded edge reported so that a consumer can tell suppression from absence? quality

Completeness declaration and enumeration frontier

Absence of an edge is not evidence of absence of dependency. CycloneDX states plainly that objects not represented in the dependency graph may have unknown dependencies and that implementations should treat this as opaque rather than as dependency-freedom; RDF is a purely assertional language with no way to express absence; SPDX therefore carries an explicit three-valued completeness marker on the relationship itself. This finding requires a scoped completeness declaration naming the node scope, relation types and traversal depth actually enumerated, the gaps recorded as known unknowns, and the flag that licenses a closed-world reading. Any negative conclusion must cite a resolvable declaration that covers the queried scope.

1. Is the enumerated edge set for this scope complete, incomplete, or is no assertion made? validation
2. Which node scope, relation types and traversal depth does the completeness declaration actually cover? composition
3. Which gaps are declared as known unknowns rather than treated as absent edges? evidence
4. What licenses a closed-world reading so that absence of an edge may be read as absence of dependency? constraint
5. How long does a completeness declaration remain valid, and what invalidates it? lifecycle

Declared analysis run over a named snapshot

A derived result is admissible only as a projection carrying: the algorithm identifier and version, the full parameter set, the edge-selection filter (relation types, licence profile, modality inclusions, exclusions applied, temporal reference), the digest of the immutable input edge set, the run execution time, a determinism class and any supersession pointer. This mirrors how graph analytics actually behave, computing over a projected in-memory graph whose results reflect that projection at execution time. The model records the run; it never executes it, and it holds no claim over the evaluator's own execution logs or audit records.

1. Which algorithm identifier and version produced this derived result? identity
2. Which parameters, edge filters and modality inclusions defined the analysed subgraph? process
3. Against which immutable snapshot of the asserted edge set was the run executed? provenance
4. Is the result reproducible from the recorded snapshot and parameters, and where is it not? quality
5. What makes a stored projection stale, and how is supersession recorded? state

Path results, path restrictors and alternative paths

A path result is uninterpretable until its restrictor is declared. ISO/IEC 39075 fixes the distinctions normatively with walk, trail, acyclic and simple restrictors controlling whether nodes or edges may repeat, alongside match modes and path search. A path result must therefore state its restrictor, direction, depth or hop bound and what happened at that bound, and whether it claims all paths, shortest paths, k paths or a single witness. Alternative-path counts are only meaningful with a declared disjointness criterion, which is the success-path dual of the cut-set view in reliability modelling.

1. Which path restrictor governs the result: walk, trail, acyclic or simple? definition
2. What depth or hop bound and traversal direction were applied, and what happened at the bound? constraint
3. Does the result claim all paths, shortest paths, k paths, or a single witness path? classification
4. How many node-disjoint or edge-disjoint alternative paths exist between the two endpoints? measurement
5. How is an individual path addressed and compared across runs? identity

Cycles, strongly connected groups and closure safety

Directed dependency graphs are not reliably acyclic. A strongly connected component is a maximal set of nodes with a directed path between every pair, and its presence changes what may be claimed: unbounded transitive closure over a cycle does not terminate, topological ordering is undefined inside a component, and shortest-path depth claims must state their restrictor. This finding records component membership, cycle witnesses, the acyclic condensation where computed, and an explicit closure-safety marker stating whether transitive or ordering claims over the analysed subgraph are sound.

1. Does the analysed subgraph contain directed cycles, and which edges witness them? state
2. Which nodes form strongly connected groups, and how is each group addressed? relationship
3. How do detected cycles constrain transitive closure, ordering and depth claims? constraint
4. Is the acyclic condensation of the graph recorded, and how does it relate to the original asserted edges? composition

Reachability, negative claims, fan-in, fan-out and cut sets

The impact answer itself: the set reachable from a seed under the declared licence, modality and temporal filters, together with the structural measures built on that traversal - fan-in and fan-out degree, minimal cut sets whose removal disconnects a seed from a target, and the count of surviving alternative paths. Fault tree analysis supplies the cut-set vocabulary and the discipline of identifying assumptions and event boundaries explicitly; reliability block diagrams supply the dual success-path view. The controlling rule is asymmetric: a positive reachability claim needs only the traversal record, while any negative claim - not reachable, not impacted, no dependency - additionally requires a resolvable completeness declaration with the closed-world flag covering the queried scope.

1. Which nodes are reachable from the seed under the declared licence, modality and temporal filters? relationship
2. On what basis may this result state that a node is not reachable or not impacted? validation
3. What are the fan-in and fan-out degrees of the node, and over which edge selection were they counted? measurement
4. Which minimal sets of nodes or edges, if removed, disconnect the seed from the target? decision
5. How is a what-if impact answer over hypothetical or removed edges kept separate from the actual-state answer? exception

Change, event and hypothetical trigger input

States exactly what is being analysed and of what kind: a proposed change not yet made, an event that occurred, a hypothetical stress condition, or a standing condition. The trigger is always carried as a resolvable reference to its owning record plus the impact-specific seed parameters - which entities it acts on and what property of each is altered - so that the analysis never becomes a second master record for the change or the incident.

1. What exactly is the analysed trigger - a proposed change, an occurred event, a hypothetical stress condition or a standing condition - and how is that distinction recorded rather than inferred? definition
2. Which authoritative record identifies the trigger, and which identifier resolves it in its owning system? identity
3. Which entities does the trigger act on directly, and which property or capability of each is altered, degraded or lost? relationship
4. What magnitude, duration or severity is assumed for the trigger itself, and is that assumption stipulated, measured or inherited from the owning record? measurement

Scenario identity, version and declared input set

Fixes the impact scenario as a versioned object that can be cited, compared and refuted: its identifier and version, the dependency-graph snapshot and snapshot time it was evaluated against, its stated assumptions and parameters, the alternatives it is one of, and whether it is draft, released or superseded.

1. Which identifier and version distinguish this scenario from every other scenario evaluated for the same trigger? identity
2. Against which dependency-graph snapshot, taken at which snapshot time, was this scenario evaluated? provenance
3. Which stated assumptions, parameters and option choices together constitute the scenario's declared input set? composition
4. When a scenario input changes, does the scenario mutate in place or is a superseding version issued, and what happens to results already derived from it? lifecycle
5. Which other scenarios are declared as alternatives or comparators for the same trigger, and on what dimension do they differ? relationship

Counterfactual baseline and comparison basis

Declares what the scenario is compared against: the current state, a projected likely evolution without the trigger, or an explicit counterfactual alternative - and whether effects are reported as differences from that baseline, as absolute end states, or both. An impact assertion without a declared baseline is not falsifiable, so 'no baseline declared' is itself a recorded, disclosable value rather than an absence.

1. Against which baseline state is the scenario's effect measured, and is that baseline a static observed state or a projected evolution without the trigger? definition
2. Which observation, register or model produced the baseline values, and at what time were those values observed or projected? provenance
3. Is a reported effect expressed as a difference from baseline, as an absolute end state, or as both, and is that choice uniform across the result set? measurement
4. What happens to results already published when the baseline is revised or found to be wrong? lifecycle
5. Under what conditions may an assessment be issued with no declared baseline, and how is that limitation surfaced to a consumer? exception

Analysis mode, time separation and effect horizon

Separates prospective analysis from retrospective observation and from reconciliation of the two; records analysis time, trigger time, expected effect time and observation or ingestion time as distinct values; and bounds the horizon over which effects are in scope, including short, medium and long-term banding, permanence and reversion time, plus the organisational, contractual and geographic scope of the analysis.

1. Is this record a prospective analysis, a retrospective observation or a reconciliation of the two, and how is that mode declared rather than left to be inferred from timestamps? classification
2. Are the analysis time, the trigger time, the expected or observed effect time and the observation or ingestion time recorded as four separate values? temporal
3. Over what horizon are effects in scope, and how does this Dimension define its short-, medium- and long-term bands? constraint
4. Is each expected effect classified as temporary or permanent, and is a recovery or reversion time recorded where it is temporary? state
5. Which organisational, contractual or geographic scope bounds this analysis, and what is explicitly outside it? spatial

Propagation rules, traversal limits and non-propagating dependencies

The reusable, versioned rule set governing traversal: which declared edge types propagate effect and in which direction, which are asserted non-propagating, the depth limit and stop conditions, which steps are conditional on a stated predicate, and how cycles, redundancy, failover and aggregation edges are handled. Direct versus indirect effect is defined here in traversal terms and explicitly distinguished from domain notions of secondary or cumulative effect.

1. Which declared dependency edge types are treated as propagating for this scenario, and which are declared non-propagating with what justification? classification
2. In which direction is traversal performed, and at what depth or under which stop condition does it terminate? constraint
3. How is a direct effect distinguished from an indirect effect, and does that distinction rest on traversal distance or on a domain-causal claim? definition
4. Which propagation steps are conditional, and on which predicate, configuration or state does each condition depend? requirement
5. How are cycles, redundancy, failover and aggregation edges handled so that they neither inflate nor silently suppress the affected set? process

Affected-set membership and per-entity status

The enumerated set of entities reached by the scenario, each carrying an explicit status - affected, not affected, unknown or under investigation, conditionally affected, or reached but not propagating - with a justification code and determination time. Absence from the set never means 'not affected'; negative, unknown and conditional determinations are published as members so that a shorter set cannot masquerade as a smaller impact.

1. Which entities are members of the affected set, and by which registry identifier is each one resolved? identity
2. What status does each member carry, and is a not-affected determination recorded explicitly rather than by absence from the set? state
3. What justification supports a not-affected or reached-but-not-propagating determination for a given member? evidence
4. How is 'exposed through a dependency' distinguished from 'assessed as affected' for the same member? classification
5. How are members whose status is unknown or still under investigation carried forward across scenario versions instead of being dropped? exception

Effect kind, polarity, magnitude, ordering and accumulation

Characterises each asserted effect on an affected member: what kind of effect on which property or capability, whether it is negative, neutral or beneficial, its magnitude on a referenced scale with a referenced unit, whether it is a first-order consequence of the trigger or arises only from another asserted effect, and whether it is declared to accumulate with effects from other triggers or scenarios.

1. What kind of effect is asserted on this member, and on which of its properties or capabilities does it fall? definition
2. Is the asserted effect negative, neutral or beneficial, and can a neutral or beneficial effect be represented at all in this result set? classification
3. On what scale and in what unit is effect magnitude expressed, and is that scale ordinal or quantitative? measurement
4. Which effects are first-order consequences of the trigger and which arise only from another asserted effect? relationship
5. Does this effect accumulate with effects from other triggers or scenarios, and is that accumulation declared rather than computed here? composition

Traced paths, excluded edges and traversal completeness

For each asserted member, the ordered sequence of dependency edges connecting the trigger to it, together with the edges, nodes and subgraphs excluded from traversal with a reason code, and a completeness code stating whether the traversal was exhaustive over the cited snapshot, truncated by a declared limit, limited by missing data, or sampled. This is what allows a reviewer to re-execute and refute the result.

1. Which ordered sequence of dependency edges connects the trigger to each asserted affected member? provenance
2. Which edges, nodes or subgraphs were excluded from traversal, and under which exclusion reason code? constraint
3. Was the traversal exhaustive over the cited snapshot, truncated by a declared limit, partial because of missing data, or sampled? quality
4. How is a recorded path treated when an underlying dependency assertion is later retracted, retyped or corrected in the source graph? lifecycle
5. Can a consumer re-execute the traversal from the cited snapshot, profile and code-list versions and obtain the identical result? validation

Claim status, outcome uncertainty and limitation disclosure

Qualifies every asserted outcome with its epistemic standing: whether it is a dependency-derived exposure inference, a modelled prediction, an observed outcome or an attributed cause; the likelihood or confidence qualifier on a declared scale and who assigned it; the evidence required before an attributed-cause claim may be made at all; the accountable assessor and the mandate under which the assessment was issued; and the limitations that a consumer must read with the result. It also states, as a publication condition, that no impact result is an approval, an instruction or a notification.

1. What claim status does each asserted outcome carry - exposure inference, modelled prediction, observed outcome or attributed cause? classification
2. Which likelihood or confidence qualifier is attached, on which declared scale, and which agent assigned it? quality
3. What evidence must be cited before an outcome may be published with attributed-cause status, and what is recorded when that evidence is absent? evidence
4. Which agent or role is accountable for this assessment, and under what mandate was it issued? authority
5. How may a downstream consumer reuse this result without reading it as an approval, an instruction or a notification? interoperability

Criticality assignment to a dependency

A criticality value asserted for a depended-on element as seen from one named dependent purpose, valid for a stated operating state and time window, with the deciding authority recorded. Criticality is relational, not intrinsic: the same element may carry different values for different purposes.

1. Which depended-on element and which dependent purpose does this criticality assignment bind together? identity
2. What criticality level is asserted, and under which named scheme and version is that level defined? classification
3. Which role or body determined the level, by what method, and where is that decision recorded? authority
4. For which operating state and validity window does the assignment hold? temporal
5. Does the assigned level propagate to elements the subject itself depends on, and under which inheritance rule? relationship

Scale scheme binding

The declaration that a stored criticality, severity or likelihood value belongs to a specific published scheme version, with its publisher, value space, notation and supersession status, so no single scoring doctrine is embedded as canonical.

1. Which published scheme, version and notation produced the stored value? identity
2. Who publishes and maintains the scheme, and at which authoritative location is its definition retrievable? provenance
3. May values from two different schemes be compared, and is any declared mapping between them marked lossy? interoperability
4. What becomes of stored values when the bound scheme version is superseded or withdrawn? lifecycle
5. Which scheme inputs are mandatory and which are optional or environment-specific? constraint

Downstream impact estimate

An estimate of the consequence to a named dependent if the subject is lost or degraded, recorded per consequence category and per assumed loss scenario, with sensitivity to disruption duration. It is an input to a host risk or continuity record and is never itself a risk determination.

1. Which loss scenario does the estimate assume: total loss, partial degradation, delay, or corruption of the depended-on element? definition
2. Which consequence categories are estimated, and what severity value is recorded for each? measurement
3. How does the estimated consequence change as the disruption persists? temporal
4. What evidence underpins the estimated severity and how was it obtained? evidence
5. Which host record consumes this estimate, and who owns the decision made from it? ownership

Affected set and propagation extent

A snapshot of which dependents are reached if the subject fails, at what propagation order, across which boundaries and with what timing. It is a derived view over a referenced dependency-graph snapshot, recorded with its traversal rule and assumptions so it can be reproduced or falsified.

1. Which dependents are reached by a failure of the subject, and at what propagation order is each reached? relationship
2. Which organisational, jurisdictional, network or facility boundaries does the propagation cross? spatial
3. Which graph snapshot, traversal rule and depth limit produced this affected set? provenance
4. How quickly does the effect reach each tier of the affected set? temporal
5. Which reachable paths were deliberately excluded from the affected set, and on what stated ground? exception

Likelihood, confidence and residual uncertainty

Qualification of an estimate: the likelihood or frequency assigned to the assumed disruption over a stated horizon under a named scheme, together with asserted confidence, its evidential basis, the residual uncertainty that remains and the conditions that invalidate the estimate. Likelihood (about the world) and confidence (about the assessment) are recorded separately and never collapsed.

1. What likelihood or failure frequency is assigned to the assumed disruption, over which horizon and under which likelihood scheme? measurement
2. What confidence is asserted in the estimate, and is it derived from evidence quality, assessor agreement or a stated model? quality
3. What residual uncertainty, unmodelled factor or known unknown remains after the estimate is made? evidence
4. Which change in the underlying facts marks the estimate stale and triggers reassessment? validation
5. Who produced the estimate, and were independent reviewers or dissenting judgements recorded? provenance

Declared substitute or alternate

An alternative that can carry the dependent's need if the subject is unavailable, recorded with equivalence class, invocation preconditions, capacity and duration limits, switchover cost and the evidence that it has been verified. Declaration is not capability: unverified substitutes are marked as such.

1. Which alternative element can carry the need, and is it a full, partial or degraded-mode equivalent? identity
2. Under which declared preconditions is the substitution considered available and valid? constraint
3. What capacity, throughput or duration ceiling limits the substitute, and what share of demand can it absorb? measurement
4. How long does switchover take, and what degradation or data loss is accepted while the substitute is in effect? temporal
5. When was the substitute last exercised or otherwise verified, and with what recorded result? evidence

Redundancy configuration and correlated failure

The redundant structure standing behind a dependency, expressed as a required-out-of-total configuration with its mode, together with the shared resources, suppliers, locations or designs that reduce effective independence and can defeat the redundancy at once.

1. What redundancy configuration is declared, expressed as which structure and which required-out-of-total quantity? composition
2. Which resources, suppliers, sites, code bases or time sources are shared across the redundant members? relationship
3. Which common-cause or correlated failure conditions would defeat all redundant members simultaneously? constraint
4. Is the redundancy load-sharing, so that losing one member degrades capacity rather than preserving it? state
5. Which dependability analysis method produced or supports the configuration, and what assumptions did it declare? evidence

Single point of failure and concentration exposure

The derived determination that a subject is a single point of failure for a named dependent, and the measured convergence of many dependents on one element, supplier, jurisdiction or facility. Both are derivations with a recorded rule version and trace, contestable and reversible, not standing labels.

1. Is the subject a single point of failure for the named dependent, and from which recorded facts was that concluded? decision
2. How many distinct dependents converge on this element, and what share of them carry a high criticality level? measurement
3. At which level does the concentration exist: element, product, supplier, jurisdiction or shared facility? classification
4. Which change of state would remove the single-point-of-failure determination? state
5. Which determinations are contested or overridden, by whom and on what stated ground? exception

Mitigation and treatment reference

Outward pointers from a criticality or resilience record to externally owned mitigations, controls, continuity plans and treatment decisions, together with the credited effect on the local estimate and the residual value after crediting. The reference carries no ownership of the mitigation's approval, execution, testing or audit trail.

1. Which external mitigation, control or continuity record is referenced, and in which owning system does it live? identity
2. Which local estimate does the referenced mitigation modify, and is the stored value recorded before or after crediting it? relationship
3. What residual criticality or impact remains once the mitigation is credited? measurement
4. What evidence shows the mitigation was in force at the moment the estimate was asserted? evidence
5. Who owns approval, execution and effectiveness testing of the referenced mitigation? ownership

Governance role archetype catalogue

A governed, extensible catalogue of the seven generic archetypes an agent may occupy with respect to a dependency or impact assertion - issuer, endpoint steward, reviewer, approver, observer, analyst and exception authority - each with a definition, the governance acts it may originate, and the acts it is explicitly not accountable for. Archetypes are abstract role concepts in the PROV-O sense; the adopting Dimension maps them to its own job titles, committees and delegated bodies without this model prescribing an organizational form.

1. What exactly does each governance role archetype mean for a dependency or impact assertion, and which governance acts is it competent to originate? definition
2. Where does one archetype's accountability stop and the next archetype's begin, so that no act is unowned and no act is doubly owned? authority
3. How may an adopting Dimension add a locally required archetype without breaking interoperability of the generic set? classification
4. How does a given archetype map onto external role vocabularies so that governance data remains exchangeable? interoperability

Endpoint stewardship and cross-boundary accountability

A dependency assertion has at least two ends, and the source and target may sit under different owners, organizations or contracts. This finding models the endpoint-steward binding for each end of the assertion, the case where the counterparty end is outside the adopting Dimension's control, and the resulting accountability asymmetry: an issuer may assert a dependency on an endpoint it does not steward, but cannot bind that endpoint's steward to any obligation.

1. Which agent is the accountable steward of each end of this dependency, and is that end inside or outside the adopting Dimension's control boundary? ownership
2. Has the counterparty steward acknowledged the asserted dependency, and what is the governance status when it has not? relationship
3. When an endpoint is itself a composite, at which level is stewardship asserted and how does it decompose? composition
4. What happens when no steward can be identified for an endpoint that a critical impact path traverses? exception

Segregation-of-duties declarations for dependency governance

Declarative statements of which archetype combinations one agent must not hold simultaneously for the same assertion, which acts require two distinct persons, and where self-review or self-approval is prohibited. These are constraint declarations supplied as attributes to an external decision point; this model records the rule and any recorded conflict observation, and never blocks an operation itself.

1. Which pairs or sets of role archetypes are declared incompatible for the same agent on the same dependency or impact assertion? constraint
2. Which governance acts require two distinct natural persons, and how is distinctness determined? validation
3. When a duty conflict is observed on an existing assignment, what is recorded and who must act on it? decision
4. How is cumulative privilege across delegated bindings assessed so that separation is not defeated by aggregation over time? security

Role binding, term and delegation chain

The qualified attribution that binds one archetype to one agent for a stated scope of dependency or impact assertions over a stated validity period, together with the delegation chain when an agent acts on behalf of another and the succession rule when a binding lapses. Modelled on the PROV-O qualified-attribution pattern and the validFrom/validUntil plus status pattern of verifiable credentials.

1. How is a single role binding identified and distinguished from every other binding of the same agent and archetype? identity
2. What states may a role binding occupy between proposal and termination, and what triggers each transition? lifecycle
3. When an agent acts on behalf of another for a governance act, how is the delegation chain recorded and bounded? provenance
4. Over which validity period is the binding effective, and how are effective time and record time distinguished? temporal

Purpose and jurisdiction qualifiers on governance acts

Every governance act recorded by this model must declare the purpose for which it was performed and the jurisdiction or territorial scope under which it is claimed to be valid. Both are carried as references into externally governed code lists - a purpose vocabulary and a jurisdiction registry - so that the model can require the qualifier without asserting any doctrine about what a jurisdiction is or which law prevails.

1. For what declared purpose was this governance act performed, and from which governed vocabulary is that purpose drawn? requirement
2. Which jurisdiction or territorial scope is claimed for this act, and how are multiple or conflicting claims represented? spatial
3. Does the governance record contain personal data about the bound agent, and what minimisation applies? privacy
4. How do purpose and jurisdiction qualifiers reach the systems that decide who may read the governance record? access

Review and approval decision record

A separately attributed decision record stating that a named reviewer examined a dependency or impact assertion and that a named approver accepted or rejected it, with the decision outcome, its stated basis, the effective time of the decision and the conditions attached. Reviewer and approver are distinct archetypes: review establishes technical adequacy, approval constitutes acceptance of the residual consequence.

1. What sequence of review and approval steps is required before a dependency or impact assertion is treated as governed, and what is the timeliness expectation for each? process
2. What governance standing does an assertion hold at any moment, and how is that standing represented when review has expired or been withdrawn? state
3. On what stated basis was the decision reached, and what supporting material is cited without being reproduced? evidence
4. How is the adequacy of the review itself judged, and what makes a decision record defective? quality

Contested, unknown and no-assertion handling

Treatment of dependency or impact assertions whose existence, direction, scope or severity is disputed. Distinguishes a positive assertion that no dependency exists from an absence of any assertion, records the contesting party and grounds, holds the assertion in a contested state without silently deleting it, and names the authority competent to resolve - including an escalation path when the contest crosses an organizational boundary.

1. What event opened the contest, who raised it, and against which specific element of the assertion? event
2. How is a positive statement that no dependency exists distinguished from the absence of any statement, and from an unresolved contest? classification
3. Which authority is competent to resolve this contest, and what is the escalation path when the parties sit under different owners? decision
4. How long may a contest remain open, and what is recorded when it exceeds that period? temporal

Exception grant and accountable exception authority

A record that a named exception authority, acting within a declared scope of competence, granted a time-bounded waiver of a specific governance requirement for a specific dependency or impact assertion, with the compensating conditions, the expiry and the named agent accountable for the residual consequence. Modelled on the authorization decision as an explicit, time-bounded acceptance of residual risk rather than a silent rule suppression.

1. Which authority is competent to grant this exception, and what is the ceiling on that competence? authority
2. Precisely which governance requirement is waived, for which assertions, and what remains in force? exception
3. When does the exception expire, and what is the recorded consequence of expiry without renewal? temporal
4. What constraints prevent an exception from becoming a permanent substitute for compliance? constraint

Sensitivity, access, retention and legal-hold referral markers

Governance records about dependencies are frequently sensitive: they name accountable individuals, expose organizational weak points and identify unacknowledged external reliance. This finding declares the markers carried on each governance record - a sensitivity and access classification supplied as attributes to the external decision point, a retention-class reference into the records model, and a legal-hold marker with its provenance - together with the explicit statement that classification is not authorization, that this model is not an audit store, and that suspension of disposition is executed and adjudicated elsewhere.

1. How sensitive is this governance record, and on what basis was that classification assigned? privacy
2. Which attributes does this model expose so that an external decision point can decide who may read the record, and what does it deliberately not decide? access
3. Which retention class applies to this governance record, and who owns the disposition decision and its execution? retention
4. Is this governance record under a legal or investigative hold, and what does the marker permit and forbid locally? evidence
5. How is the boundary maintained between a governance record held here and the audit trail held in the referenced audit model? interoperability

Record identity and identifier priority

A dependency edge and an impact assessment are each first-class records requiring a stable identifier that is independent of the endpoints they relate. Identity is bound in strict priority: an authoritative master-system identifier where one exists; otherwise a governed global identifier or IRI issued under a delegated namespace authority; otherwise a UUID (UUIDv7 preferred) or ULID minted by the adopting Dimension. Endpoint references are separate fields, never a substitute for edge identity, and no date, version tag or content digest may serve as the identifier.

1. Which identifier is authoritative for this dependency or impact record, and which system assigned it? identity
2. What authority delegated the namespace under which this identifier was assigned, and what persistence commitment applies? authority
3. How are the source and target endpoints of the edge referenced without collapsing them into the edge identifier? constraint
4. Which alternate or legacy identifiers map to this record, and are any of them known to be non-unique? interoperability

Namespace, tenancy and adopting-Dimension partitioning

Every governed record belongs to exactly one namespace partition owned by one adopting Dimension, expressed as a URN namespace identifier or an HTTP base IRI with a documented assignment authority. Tenancy is a partition of the identifier and canonicalization space, not an access-control mechanism: cross-tenant references are permitted only as explicit external references with their own namespace prefix, and identifier collision across tenants is prevented by namespace, never by hoping for UUID uniqueness alone.

1. Which adopting Dimension owns this namespace partition, and who is the accountable owner package? ownership
2. Is the namespace expressed as a URN namespace identifier or an HTTP base IRI, and what string form do namespace-specific parts take? classification
3. Under what conditions may a record in one tenant partition reference a record in another? constraint
4. How are resolution and service parameters kept out of the persistent identifier itself? access

Canonical form, digest and artifact integrity

Canonicalization is defined per shape family, not per file format. Tree-shaped projections canonicalize under the JSON Canonicalization Scheme, which sorts properties lexicographically, removes whitespace, serializes numbers by ECMAScript rules and forbids duplicate keys. Graph-shaped projections canonicalize under RDFC-1.0, which assigns deterministic blank-node labels. A record's digest is computed over the canonical byte stream of a named shape, and the shape name is always carried with the digest. Because the two algorithms operate on different data models and JCS performs no Unicode normalization, digest equality across shape families is not asserted.

1. Which canonicalization profile applies to this record, and over which shape family was it computed? definition
2. How are impact scores and other numeric values represented so that canonicalization does not silently change their precision? constraint
3. What digest algorithm and encoding bind this record's canonical form, and how is the binding verified? evidence
4. How are string comparisons handled when the canonicalization algorithm does not normalize Unicode? quality

Projection profiles and loss disclosure

Every concrete serialization or store is a projection of the abstract record and must be governed by a projection profile that states which elements survive, which are transformed and which are dropped. Known lossy cases are normative examples rather than exhaustive: merge-patch-style documents cannot distinguish a null value from a deletion, arrays are replaced wholesale, absence semantics such as an explicit no-relationship assertion versus a no-assertion statement do not survive into formats lacking that distinction, and stores that normalize timestamps to UTC discard the recorded offset. A projection that cannot carry an element must disclose the loss rather than silently degrade.

1. Which projection target does this profile describe, and which shape family and canonicalization profile does it use? interoperability
2. Which elements of the abstract record are dropped, coerced or restructured by this projection? evidence
3. Is a round trip through this projection lossless, and what test demonstrates the answer? quality
4. How does this projection represent an explicit assertion that no dependency exists versus an absence of any assertion? exception
5. How is a partial projection addressed and named so that consumers can tell which subtree or subgraph they received? composition

Version identity, patch grammar and compatibility classes

A record version is an immutable, digest-bound state linked to its predecessor by a previous-version relation, forming an auditable chain. Mutations are expressed as patch documents: an operation-sequence grammar with pointer targets, test preconditions and all-or-nothing application is the default; merge-patch grammar is permitted only for object-shaped subtrees that contain no explicit nulls and require no partial array edits; graph-shaped records use a canonicalized add/remove quad set. Every patch carries the expected pre-state digest and the resulting post-state digest, and declares a compatibility class: additive, corrective, or restrictive (breaking).

1. Which version of this record does the current state supersede, and how is the chain verified? lifecycle
2. Which patch grammar was used for this change, and why was it admissible for the affected subtree? process
3. What precondition guarded this patch against applying to an unexpected state? constraint
4. What compatibility class does this change carry for downstream consumers of the affected dependency edge? decision

Clock discipline and temporal validity

All time values are recorded as internet timestamps with seconds and an explicit offset or the Z designator. Three time axes are kept distinct and are never collapsed: the asserted event time at which the dependency or impact fact holds or held; the validity interval of the edge itself, expressed as a start and optional end; and the observation or ingestion time at which the record was captured by this model. Where the true local offset is unknown but the instant is known in UTC, the unknown-offset convention is used rather than falsely asserting Z. Leap-second values are accepted on input and their normalization must be disclosed.

1. For this record, what are the asserted event time, the edge validity interval and the observation or ingestion time? temporal
2. Which clock source produced each timestamp, and what is its known accuracy or skew? provenance
3. Was any recorded offset normalized or discarded on storage, and where is that disclosed? constraint
4. How is an open-ended or not-yet-known end of a dependency's validity distinguished from an asserted permanent dependency? exception

Validation profile, severity and conformance claim

Validation is performed against a named shapes or schema graph at a stated version; the outcome is a report stating overall conformance plus individual results, each carrying the focus node, the path, the value, the source constraint and a severity of informational, warning or violation, with violation as the default. Conformance is claimed only against a named profile and a named validation run: a record with no violations under profile A is not thereby conformant to profile B. This model owns the request for validation and the retention of its report; it does not own the validation engine, and it never converts a validation outcome into an authorization or enforcement decision.

1. Against which named validation profile and version was this record checked? validation
2. What is the conformance outcome, and which individual results were produced? requirement
3. How does the adopting Dimension treat warnings and informational results that do not block conformance? quality
4. Which external engine executed the validation, and what stops its outcome from being treated as an authorization decision? authority

Provenance, attribution and custody of assertions

Every dependency edge and impact assessment is an assertion by some agent, derived from some evidence, produced by some activity. Provenance records which agent the assertion is attributed to, which activity generated it, which prior record it was derived or revised from, and which evidence supports it, including references and digests of external supply-chain evidence such as build attestations or bills of materials. Custody records the chain of responsible parties as the record moves between systems. Evidence is referenced by identifier and digest; this model does not verify signatures, evaluate trust or operate an attestation service.

1. To which agent is this dependency or impact assertion attributed, and in what role? provenance
2. From which prior record or source was this assertion derived or revised, and by what activity? lifecycle
3. What external evidence supports this dependency edge, and how is it addressed immutably? evidence
4. Which parties have held custody of this record since assertion, and where did responsibility transfer? ownership
5. What verification of the supporting evidence has this model performed, and what has it deliberately not performed? security

Query, mutation and delegated retention, access and audit boundaries

The operating surface is declared as capabilities, not endpoints: which selection expressions are supported and in what expression language, whether results are complete or truncated, which mutation operations are accepted and under what preconditions, and which projections are offered. Retirement of a record produces a tombstone that preserves the identifier, final digest, disposition reason and the policy reference authorising disposition, so that dangling references resolve to an explicit retired state rather than silently disappearing. Execution of erasure in downstream stores, the access decision itself, and the audit trail are owned by the adopting Dimension and the referenced retention, authorization and audit models; this model records the request, the reference and the outcome received, and never decides, enforces or stores the audit trail.

1. Which query and mutation capabilities does this deployment declare, in which expression language, and with what completeness guarantee? process
2. What retention class applies to this record, which policy governs its disposition, and which party executes the disposition? retention
3. What does a retired dependency record leave behind so that inbound references remain resolvable? state
4. Which external authority decides who may read or change a record, and what does this model contribute to that decision? access
5. Which governed operations must emit an audit event, and which model owns the resulting trail? interoperability

Command inventory and permitted state transitions

Enumerates the mutation commands defined for a dependency or impact statement (declare, validate, review, approve, activate, revise, correct, supersede, retire, observation-update), the lifecycle state each produces on the subject statement, which state-and-command pairs are legal, and how content-affecting commands are distinguished from workflow-only ones. The state spine is a specialization of the draft/active/retired/unknown publication vocabulary; refinement states such as in-review and approved are adopting-Dimension additions and are marked as such rather than claimed as standard.

1. Which mutation commands are defined for a dependency or impact statement, and which lifecycle state does each one produce? lifecycle
2. Which state-and-command pairs are permitted, and which transitions must be rejected as invalid rather than silently ignored? state
3. How is a command that changes asserted meaning distinguished from one that only moves workflow state? classification
4. Which commands may be issued by an automated agent without human review, and which require a human authority? authority

Review, approval and activation authority gate

The contract for the review, approve and activate commands: what a review disposition may say, which authority reference an approval must carry, when the approver must differ from the declarer, and how an emergency bypass is recorded. The disposition recorded here is a judgement about the fitness of the dependency statement, deliberately separate from any access-control decision, which is referenced from the authorization model and never rendered here.

1. What disposition values may a review record carry, and which of them permit the statement to proceed to approval? decision
2. Which authority reference must an approval record carry, and how is the approver's competence over this statement established? authority
3. Under what conditions must the approver differ from the declarer, and how is that separation evidenced? constraint
4. How is an emergency or break-glass approval recorded so that retrospective review is guaranteed? exception

Command envelope and admission preconditions

The interface-neutral envelope that accompanies every mutation command: command identity, acting agent and submitting software, subject statement binding, authorization decision reference, audit hook reference, required inputs per command type, and the timestamps that must be captured. Endpoint references named in a declare command must resolve, but resolving them is a read against the endpoint's owning model; the command never creates or alters an endpoint record.

1. Which identifier identifies a mutation command instance, and what is used when no master-system identifier exists? identity
2. Which envelope fields must every state-changing command carry before it can be admitted? requirement
3. How are the acting agent, the software that submitted the command, and the consulted authorization decision recorded as provenance? provenance
4. Which timestamps must a command record, and how are submission, decision and effective times kept apart? temporal

Validation contract and outcome reporting

The contract for the validate command: which classes of check run (envelope completeness, reference resolvability, transition legality, and the statement invariants defined by the structural area and referenced schemas), which findings block a transition and which are advisory, and what the outcome record must contain to be reproducible. Validation evaluates invariants owned elsewhere; this contract owns only when validation runs, what its outcome contains and whether an outcome blocks.

1. Which classes of check does the validate command run, and which of them block a transition rather than warn? validation
2. What does a validation outcome record contain so that a failure is reproducible against a specific statement version? evidence
3. Who owns the invariant definitions that validation evaluates, and how are they referenced rather than restated here? ownership
4. How are advisory findings, unresolved references and explicit no-assertion values reported without blocking the command? quality

Idempotency scope, fingerprinting and replay behaviour

Defines when a repeated command is a replay that must return the original result rather than create a second statement, how the request fingerprint is computed over a canonical form, which envelope fields are excluded from the fingerprint, how long a key is honoured, and what happens when the same key arrives with different content. Declare is made effectively idempotent by a uniqueness criterion in the same style as a conditional create; review, approve, activate, supersede and retire are naturally idempotent because a repeated invocation leaves the intended state unchanged.

1. What makes a repeated submission of the same command a replay rather than a new mutation? process
2. How is the request fingerprint computed, and which envelope fields are excluded from it? identity
3. For how long is a replayed key honoured, and what happens after that window expires? temporal
4. What must happen when the same idempotency key arrives with a different payload? exception

Version preconditions, conflict outcomes and atomicity

Requires every version-producing command to carry an expected-version precondition so that a concurrent writer cannot be overwritten unnoticed, defines how a precondition failure is reported distinctly from an illegal-transition conflict, fixes the atomicity unit when one command touches several statements, and states how these interface-neutral preconditions bind to a concrete protocol.

1. Which precondition must a version-producing command carry so that a lost update is impossible? constraint
2. How is a precondition failure distinguished from a state-machine conflict in the outcome? state
3. When one command touches several statements, what is the atomicity unit and what is rolled back on partial failure? process
4. How do these preconditions bind to a concrete interface without the model itself depending on that interface? interoperability

Immutable version identity, correction and supersession

Fixes the identity of a historical version as the pair of statement identifier and version token, forbids reuse of a token, and separates three distinct acts: revision, which asserts a changed but legitimately new state of affairs; correction, which marks an earlier version as erroneous without denying that it was recorded; and supersession, which closes one statement's currency in favour of a successor. Retirement ends applicability without asserting error. In all cases prior content remains readable and is never overwritten.

1. What identifies a specific historical version of a statement, and why can that identity never be reused? identity
2. How does a correction of an erroneous record differ from a revision and from a supersession in what each asserts about the past? lifecycle
3. Which validity interval does supersession close, and how is that different from the record's transaction time? temporal
4. What must remain readable after retirement, and what may never be overwritten by a later change? retention
5. How is the link from a superseded statement to its successor represented so that both directions are traversable? relationship

Observation-update command for machine-asserted dependency facts

The contract for refreshing a statement from automated observation: which observer, procedure and confidence must accompany the update, how the time the dependency condition held is kept separate from the time the observation completed or was ingested, how an observer expresses that a dependency is no longer present as opposed to unknown, and when an observation may change a statement directly rather than being attached as competing evidence to a human-declared one.

1. Which observer, procedure and confidence values must an observation-update carry to be usable as evidence? measurement
2. How are the time the dependency condition held and the time the observation was completed or ingested recorded separately? temporal
3. How does an observation that no longer sees a dependency express absence rather than ignorance? quality
4. When does an observation-update supersede a human-declared statement, and when must it only be attached as competing evidence? decision

Result, failure, emitted events and side-effect containment

Specifies the success result a caller receives (resulting state, new version token, produced record references), the structured failure representation that distinguishes retryable conditions from ones requiring a corrected request without leaking exploitable detail, the change events that must be emitted with an envelope whose identity is unique per producer, and the containment rules: a command may create or modify only records this model owns plus the named statement, and may never create, modify or delete an endpoint record, evaluate or enforce a policy, write audit evidence, or trigger resolution, deployment, remediation or notification delivery.

1. Which change events must a command emit, and which envelope attributes make an event uniquely identifiable and correlatable? event
2. What does a successful command return so that a caller can act without re-reading the statement? requirement
3. How are failures represented so a caller can tell a retryable condition from one that requires a corrected request? exception
4. Which records outside this model's boundary must a command never create, modify or delete? constraint
5. Which downstream actions must a command never trigger directly, and how is that separation expressed in the effect list? process

Current stored-assertion read contract

Contract for returning the dependency assertions an adopting Dimension currently holds for a resolved subject endpoint: which filters are honoured, how each returned edge is marked as stored rather than inferred, observed or scenario-derived, and which provenance references travel with each edge. No inference is performed implicitly.

1. Which subject endpoint identifier anchors the read, and under which identifier authority is it resolved? identity
2. Which edge types, roles and attribute predicates constrain the returned assertion set? constraint
3. How does the response mark each returned edge as a stored assertion rather than an inferred, observed or scenario result? classification
4. Which agent asserted each returned edge, on what evidence, and when was that assertion recorded? provenance

As-of read and temporal axis binding

Contract for reading assertions as they stood at a stated point. The read must name the axis it binds (the period during which the dependency held, versus the time the assertion was recorded or observed), disclose how a requested instant was resolved to an available reference point, and behave explicitly when the request falls outside the retained horizon.

1. Does the as-of instant apply to the period the dependency held, or to the time the assertion was recorded or observed? temporal
2. How is a requested instant resolved when no reference point exists exactly at it, and how is the resolved point disclosed? process
3. How are retroactive corrections represented so that repeating the same as-of read can legitimately return a different answer? provenance
4. What is the earliest retained reference point, and how is a request before that horizon answered? exception

Endpoint-neighborhood traversal contract

Contract for bounded expansion from one or more seed endpoints: explicit direction, depth, breadth and budget bounds, how repeated visits and parallel edges are handled, how multiple seeds combine, and mandatory stop reasons so a partial region is never mistaken for the whole region.

1. In which direction is the neighborhood expanded, and how is that direction recorded on every returned edge? relationship
2. Which depth, breadth and budget bounds apply, and what is emitted when a bound halts expansion before the region is exhausted? constraint
3. How are repeated visits to the same endpoint and parallel edges between the same pair collapsed or preserved? quality
4. How are multiple seed endpoints combined, and is the combination a union of regions or an intersection? composition

Path query, path mode and direction-reversal contract

Contract for asking whether and how two endpoints are connected: the declared path mode governing repetition of nodes and edges, whether the answer enumerates individual paths or only reports connectivity between endpoint pairs, how cycles are kept finite, and which edge types may be traversed in reverse.

1. Which declared path mode governs repetition of nodes and edges along a returned path? constraint
2. Does the result enumerate individual paths, or report only that a connection exists between an endpoint pair? definition
3. How are cycles handled so a connectivity answer stays finite without silently dropping members of a cycle? quality
4. When traversal runs against the asserted edge direction, which edge types are semantically invertible and which must not be reversed? relationship
5. What does an unreachable determination mean, and which qualifications must accompany it? evidence

Comparison read between two bound reads

Contract for diffing two bound reads (two as-of points, two scopes, or asserted versus observed sets) into added, removed and changed edge sets, with a comparability test that prevents scope, filter, truncation or exclusion differences being reported as substantive change.

1. Which two bound reads form the comparison basis, and are their resolved scopes, filters and completeness declarations identical? validation
2. How is each difference classified between the two bases? classification
3. How are differences caused by scope, filter, truncation or authorization exclusion separated from real change? quality
4. What does an empty difference set mean, and under which declaration may it be reported as 'no change'? evidence

Scenario-bound impact projection contract

Contract for 'what is affected if X changes, fails or is removed' reads. The result is computed under a stated hypothesis and a referenced propagation rule set, is labelled derived and non-authoritative with a validity window, is never written back as a stored assertion, and cites rather than restates external status assertions.

1. Which hypothesis and which referenced propagation rule set produced this impact set? process
2. How is each endpoint in the impact set qualified? classification
3. How is the result marked as derived and non-authoritative, and for how long may it be relied on? provenance
4. Which external status assertions does the projection reference rather than restate? interoperability

Referenced dependency-health indicator read

Contract for attaching health, maintenance or support-status indicators to endpoints and edges as typed references to an external assessor's published result, carrying assessor, method version, observation time, binding target and freshness state, with no local recomputation, thresholding or verdict.

1. Which assessor, method and method version produced each referenced indicator, and when was it observed? provenance
2. To which exact endpoint or edge version is each indicator bound, and does that binding still hold at the read's reference point? identity
3. How stale may a referenced indicator be before the read must mark it expired instead of returning it silently? quality
4. What prevents this read from converting an indicator into a pass or fail verdict, a threshold breach or an alert? authority

World-scope declaration, completeness code and negative-result semantics

Every result declares the scope examined and whether that scope was exhaustively searched. Open-world reads may report only that nothing was found within the stated scope; independence may be claimed only under an explicitly declared, evidenced and untruncated closed-world scope, declared by a named authority.

1. Was the read executed under an open-world scope or an explicitly declared closed-world scope, and who declared it? authority
2. Which completeness code applies to the returned edge set, and what evidence supports a claim of exhaustiveness? evidence
3. What does an empty result mean under this declaration, and which phrasing may a consuming agent use? definition
4. Which underlying assertion sources or partitions were in scope, and which were unreachable or skipped at read time? quality
5. Under what conditions may a caller record a negative finding as a durable claim rather than a momentary observation? decision

Ordering, snapshot-bound continuation, truncation and exclusion disclosure

Contract for paged and bounded delivery: deterministic ordering that makes paging reproducible, an opaque continuation bound to one resolved scope and reference point, a truncation state that distinguishes 'more pages' from 'cut by a budget', disclosure of edges withheld by an authorization decision made elsewhere, and rules for absent or approximate match counts.

1. Which deterministic ordering makes paged results reproducible, and what happens when no ordering is requested? constraint
2. To which resolved scope and reference point is a continuation bound, and how does a caller learn that the underlying data moved during an in-progress traversal? temporal
3. How does the response distinguish an unfinished page sequence from a result cut short by a budget or limit? quality
4. How are edges withheld by an authorization decision disclosed without leaking their content? access
5. When may a total match count be omitted or approximated, and how must a caller treat a missing count? measurement

Report Instance Identity, Kind and Release Status

Establishes a report as a citable record independent of its storage or serialization: which identifier resolves it, which of the five kinds it declares, which revision and release status it carries, which agent issued it under whose delegated authority, and how it is superseded or revoked. The status of the report is deliberately distinct from the status of the change it describes.

1. Which identifier makes this report instance citable and re-resolvable independently of its file name, storage collection or serialization format? identity
2. Which of the five report kinds does this instance declare, and may a single instance declare more than one kind? classification
3. What release status does the instance carry, and which status values permit downstream citation? state
4. Which agent issued this report, and under whose delegated authority was the issuance made? authority
5. How is a report instance superseded or withdrawn, and what happens to existing citations of the superseded revision? lifecycle

Report Kinds and Their Mandatory Content Cores

Defines the five report kinds and the minimum content each must carry to be citable: what an analyze-impact report enumerates, how a dependency-conflict report expresses incompatibility and alternatives without asserting a resolution, which readiness criteria a change-readiness report must evaluate or explicitly mark unevaluated, what a mitigation-reference report may state about a candidate mitigation, and what content and handling marking a notification-content draft carries given that this model never transmits it.

1. What must an analyze-impact report contain before it may be cited as a basis for a change decision? requirement
2. How does a dependency-conflict report express incompatibility, alternative satisfiers and provided or virtual capabilities without asserting a resolution? composition
3. Which readiness criteria must a change-readiness report evaluate, and which may it only record as unevaluated? decision
4. What may a mitigation-reference report state about a candidate mitigation, and what must it leave to the remediation model? ownership
5. What content and handling marking must a notification-content draft carry, given that this model performs no transmission? access

Change Scenario and Subject Declaration

Declares the perturbation being analysed: the subject elements, the proposed action, the variants that must be reported alongside the primary scenario, the assumptions treated as preconditions rather than findings, and how a scenario is re-identified when the same change is re-analysed against a later snapshot.

1. What subject elements and proposed action define this scenario, and how is a multi-part scenario bounded? definition
2. Which scenario variants must be reported alongside the primary scenario, and how are they distinguished from it? decision
3. Which assumptions are declared as scenario preconditions rather than reported as findings? constraint
4. How is a scenario re-identified when the same proposed change is re-analysed against a later snapshot? identity

Graph Snapshot Binding and Temporal Validity

Every report binds to one immutable, digest-corroborated snapshot of the dependency graph owned by an external source of record, and records graph event time, observation or ingestion time and report issue time as separate values. Also fixes the report's validity horizon, what invalidates it earlier, and how the snapshot's own declared coverage limits are restated.

1. To which snapshot of the dependency graph is this report bound, and how is that binding kept verifiable after the graph has moved on? provenance
2. How are graph event time, observation or ingestion time and report issue time recorded when they differ? temporal
3. For how long does this report assert validity, and what invalidates it before that horizon? state
4. Which model owns the snapshot itself, and what may this report legitimately record about it? ownership
5. How does the report restate the snapshot's own declared coverage so that a reader does not mistake snapshot gaps for analysis gaps? quality

Impact Paths, Propagation Rules and Excluded Edges

How downstream impact is actually derived and made replayable: traversal direction, edge-type filters and depth or fan-out bounds; the versioned propagation rules mapping each traversed edge type to an impact class; the representation of an individual path as ordered edge steps; the register of edges not traversed with typed exclusion reasons; and how dependency strength distinctions affect propagation.

1. Which traversal direction, edge-type filters and depth or fan-out bounds produced the reported impact set? process
2. Which propagation rule mapped each traversed edge type to an impact class, and where is that rule set versioned? relationship
3. Which edges were excluded from traversal, and was each exclusion a policy choice, a traversal bound or a data gap? exception
4. How is an individual impact path represented so that a reader can replay it edge by edge? evidence
5. How are absolute, recommended and optional dependency strengths reflected in propagation weight and in the reported impact class? classification

Evidence Items, Attribution and Derivation

Each conclusion cites evidence items; each evidence item records the activity that generated it, the prior entity it was derived from, the agent responsible for it and when it was observed, so a conclusion can be re-derived or falsified. Distinguishes observed from asserted evidence, handles issuer withdrawal, and keeps the register distinct from the Dimension's audit trail.

1. Which evidence items support each reported conclusion, and how is that citation expressed as a resolvable link rather than restated prose? evidence
2. Which activity generated each evidence item, from which prior entity was it derived, and to which agent is it attributed? provenance
3. How is evidence observed by the report generator distinguished from evidence asserted by a third party? classification
4. What must be recorded when a cited evidence item is later withdrawn or revoked by its issuer? lifecycle
5. How is the report's evidence register kept distinct from the adopting Dimension's audit trail? ownership

Confidence, Completeness and Coverage Disclosure

The mandatory disclosures attached to each conclusion and to the report as a whole: a confidence value expressed on a named scale, a completeness assertion for each traversed relationship set drawn from complete, incomplete or explicit no-assertion, the fraction of the in-scope graph actually reached with a characterisation of what was not, and the method by which each was derived. Fixes the minimum disclosure set that gates release from draft.

1. What confidence value is attached to each conclusion, and on which explicitly named scale is that value expressed? measurement
2. Is each reported relationship set asserted as complete, as incomplete, or as an explicit no-assertion? quality
3. Which minimum disclosure set must be present before a report may leave draft status? requirement
4. How is a confidence value checked for consistency with the completeness and evidence it claims to summarise? validation
5. Which disclosures must survive summarisation into a shortened or executive rendition? constraint

Degraded Graph Conditions and Contested Evidence

How contradictory assertions, stale assertions, unresolvable endpoints, cycles, alternative satisfiers and partial coverage are detected, recorded and disclosed. The governing rule is that degradation is reported rather than silently resolved: both sides of a contradiction are retained, a cut cycle is disclosed with its cut point, an unknown endpoint is marked rather than dropped, and a choice point is presented without selection.

1. How are two contradictory assertions about the same edge reported without silently choosing a winner? exception
2. At what point is an assertion treated as stale, and what must the report say when it has to rely on one? temporal
3. How is an edge whose target cannot be resolved reported, and how does it affect the conclusions downstream of it? state
4. How are cycles detected, cut and disclosed so that the reported path set stays finite without hiding the cycle? constraint
5. When several alternative satisfiers exist for one requirement, how are they reported without asserting a selection? decision

Dual Rendition Traceability and Non-Authorising Handoff

The machine-readable and human-readable renditions of one report revision must resolve to the same conclusion anchors and the same evidence register, and every rendition must carry an explicit declaration of the acts it does not perform together with the model or role that owns each of those acts. Also covers who may read each rendition and how a rendition is corrected without creating a second conclusion of record.

1. How does a sentence in the human-readable rendition resolve to the same conclusion anchor and evidence citations as the machine-readable rendition? interoperability
2. What must be true before two renditions of one report revision may be published as equivalent? validation
3. Which downstream acts does this report explicitly not perform, and which model or role is named as owning each of them? authority
4. Who may read each rendition, and how does the report's handling marking constrain onward sharing? access
5. How is a rendition regenerated or corrected without creating a second conclusion of record? lifecycle

Assertion identity, direction and endpoint-role carriage

Every projection must carry a resolvable assertion identifier, the assertion's revision, the direction of the relation, and the role of each endpoint (single source endpoint versus one or more target endpoints), so that a consumer can rejoin the projection to the authoritative assertion without re-deriving it. Where the target format has no place for these, the projection must nominate a sidecar or embedded machine block rather than dropping them.

1. Which field, attribute or URI in each target format carries the authoritative assertion identifier, and is it dereferenceable? identity
2. How does the projection distinguish the single source endpoint from the one-or-many target endpoints when the carrier only has undirected or symmetric structures? relationship
3. How is 'no dependency exists' encoded distinctly from 'no assertion is being made' in each carrier? classification
4. When a carrier assigns its own identifier, such as a Git object hash or a document primary key, which identifier is authoritative for the assertion? provenance
5. What check confirms that all mandatory invariants survived a given rendering before it is stored? validation

Canonical form, deterministic ordering and integrity digest

The deterministic serialization used to compare, digest and sign a projection: recursive key ordering, whitespace suppression, number and string normalisation, a declared collation for collection ordering, and a content digest that binds the bytes. Canonical form exists for comparison and integrity, not as the published presentation form.

1. Which canonicalization algorithm and version applies to this projection profile, and what is its normative status? constraint
2. What total order is applied to the target-endpoint list and to any repeated structures, and which collation is used? constraint
3. Which digest algorithm binds the canonical bytes, and what exactly is covered by the digest? evidence
4. How are line endings, encoding and trailing bytes fixed so that the same input yields identical bytes on every platform? quality
5. Is the canonical form the published form, and if not which transformation produces the published form? decision

Per-format expressivity capability assessment

For each target format, a recorded assessment of whether it can natively express relations over more than two entities, conditions or guards on an assertion, validity intervals, and uncertainty or non-assertion - and if not, which documented workaround pattern is mandated. RDF expresses relations over more than two entities only indirectly; CSV cells hold only atomic or list values; YAML discards anchors, comments and style as presentation detail; document stores lose numeric and date type distinctions in relaxed mode.

1. Can this format natively express an assertion linking a source endpoint to several target endpoints, and if not which reification or relation-class pattern is mandated? interoperability
2. How are conditions or guards that qualify an assertion represented, and what happens to them when the carrier has no slot? constraint
3. Which time semantics can this format carry: validity interval endpoints, event time, and observation or generation time? temporal
4. How is confidence, inference status or explicit non-assertion represented without a consumer reading it as a firm claim? quality
5. Which specification clause supports each capability verdict, and when was that clause last checked? evidence

Mandatory projection loss report

A machine-readable report emitted with every projection whose target format cannot carry the full assertion semantics, naming each dropped or degraded element, the reason, the severity, and where the omitted content can still be obtained. A projection into a lossy format is only valid when accompanied by this report; silent degradation is a defect.

1. Which specific assertion elements were dropped, flattened or coerced in this rendering, and at which path? validation
2. How severe is each loss for a consumer making an impact decision from this projection? decision
3. Where can a consumer obtain the omitted content, and is that route available to the same audience as the projection? access
4. What is the wire shape of the loss report and how is it correlated with the projection it describes? interoperability
5. Which losses block emission outright rather than being reported and accepted? exception

Round-trip expectation and conformance verdict

For each projection profile, the declared round-trip class - byte-lossless, semantics-lossless, one-way presentational, or not round-trippable - and the corpus-based test that substantiates it. Filter and rendering pipelines must be idempotent, and a claim of losslessness requires a passing verdict, not an assumption.

1. What round-trip class is claimed for this projection profile, and is the claim symmetric in both directions? requirement
2. What comparison decides whether a round trip succeeded: byte equality, canonical digest equality or semantic equivalence? validation
3. Which test corpus exercises the hard cases - multi-target assertions, conditional assertions, open intervals and explicit non-assertions? evidence
4. Is repeated application of the rendering and parsing filters idempotent, and what evidence shows it? quality
5. What happens when a profile that previously claimed losslessness fails its round-trip test? process

Namespace, prefix and term binding declaration

The declared mapping from local assertion terms to stable global identifiers, the prefixes used, the resolution base, and the versioning of the mapping itself. A projection must declare its term bindings explicitly so that two projections emitted at different times cannot silently disagree about what a term means.

1. Which global identifier does each local relation type, endpoint role and qualifier map to in this projection profile? interoperability
2. Which prefixes are bound in this profile, and who governs the namespaces they abbreviate? authority
3. How are local terms with no global counterpart emitted so that consumers do not mistake them for standard terms? constraint
4. How is a change to the term binding map versioned and correlated with previously emitted projections? lifecycle

Domain-standard carrier alignment

Declared alignments between this model's dependency and impact assertions and independent domain standards for dependency information, recorded as bindings and mapping gaps rather than as conformance claims. At least two independently governed carriers are recognised so that no single consortium format is treated as canonical.

1. Which domain standards are recognised as carriers for these assertions, and which independent bodies govern each? interoperability
2. How does each local relation type map onto the target standard's relationship vocabulary, and which types have no counterpart? classification
3. Where do two recognised standards disagree about direction, cardinality or completeness semantics for the same relation? constraint
4. What evidence would be required before claiming conformance rather than alignment to a domain standard? evidence

Projection run record and derivation provenance

One record per generation, binding the source assertion revision, the profile and binding-map revisions, the executing agent, the canonical digest, the loss report and the round-trip verdict, and distinguishing the time the underlying assertion held from the time it was observed and the time the projection bytes were produced. The record's effect ends at a stored candidate; it neither publishes nor mutates any endpoint.

1. Exactly which assertion revision, profile revision and binding-map revision were consumed by this run? provenance
2. How are the assertion's own validity time, the observation time and the generation time recorded separately in this run? temporal
3. Which agent executed the run and under whose delegated authority? ownership
4. What is the run's outcome state, and which candidate artifacts did it produce? state
5. What confirms that the run performed no publication and no endpoint mutation? security

Projection profile version and compatibility declaration

The versioning contract for a projection profile: a compatibility class assigned to every change, the distinction between the profile version, the underlying specification version and the version of the assertion content described, the machine-readable change set, and the negotiation behaviour when a consumer asks for an unsupported version.

1. What compatibility class does this profile change carry, and which consumer behaviour would break without a major increment? constraint
2. Which distinct versions must a consumer read: the profile version, the underlying format specification version, and the version of the described assertion content? interoperability
3. How is the difference between two profile revisions expressed so a consumer can apply it mechanically? process
4. What does a reader receive when it requests a profile version the emitter does not support? exception
5. How long does a superseded profile version remain readable, and who decides its removal? retention