03 / The attribution graph

Six product layers, one compact graph.

The customer-facing chain spans invocation, service, code, identity, organization, and budget. The engineering graph uses five nodes and eight relations; financial allocation remains separate from ownership.

Mechanism

Inspect the attribution engine

Question

How does the graph connect AI usage to an accountable owner without forcing a complete path?

Mechanism

How the mechanism works

Five engineering node types keep the graph compact. Eight governed relation types define the eligible structural paths. Budget responsibility remains organization context and a governed relationship, rather than becoming a sixth engineering node.

Invocation: The governed model-use record
Service: The runtime service or workload context
Project: The code or project ownership context
Identity: Human, service, shared, or transient identity
Organization: Event-time organization and budget context

Eight governed relations
Source	Target	Expected when	Absence valid	Evidence examples	Possible output states
Invocation	Service	A service context is available for the invocation	Yes	Gateway workload, runtime trace, provider metadata	Deterministically resolved, Strongly inferred, Ambiguous, Unknown, Not identifiable
Invocation	Identity	An eligible human, service, shared, or transient identity is observable	Yes	Service identity, user context, credential metadata	Deterministically resolved, Strongly inferred, Bounded, Ambiguous, Unknown, Not identifiable
Invocation	Project	The invocation carries eligible deployment or project context	Yes	Deployment identifier, job metadata, project binding	Deterministically resolved, Strongly inferred, Ambiguous, Unknown
Service	Identity	A service identity or governed operator relationship exists	Yes	Identity directory, workload identity, service-account binding	Deterministically resolved, Strongly inferred, Bounded, Unknown
Service	Project	A deployed service can be connected to a governed project	Yes	CI/CD metadata, deployment manifest, source-control binding	Deterministically resolved, Strongly inferred, Ambiguous, Unknown
Identity	Organization	An event-time organization relationship is available	Yes	Directory group, effective-dated organization hierarchy	Deterministically resolved, Strongly inferred, Bounded, Unknown, Not identifiable
Identity	Project	A governed identity-to-project relationship is eligible	Yes	Repository membership, deployment role, project access metadata	Deterministically resolved, Strongly inferred, Ambiguous, Unknown
Project	Organization	A governed owning organization relationship exists	Yes	Code ownership, project catalog, organization hierarchy	Deterministically resolved, Strongly inferred, Bounded, Ambiguous, Unknown

Annotated visual

Inspect the path and its unresolved states

Six product layers to five engineering nodes

Product layers

Model invocation
Service
Code or project
Identity
Organization
Budget responsibility

Evidence and time basis resolve at the measurement point

Engineering nodes

Invocation
Service
Project
Identity
Organization includes budget context

In summary: model invocation maps to Invocation, service to Service, code or project to Project, identity to Identity, and both organization and budget responsibility to Organization context. The graph contains five node types. Budget allocation remains a separate result.

Concrete example

Apply the mechanism to one synthetic workload

Workload: support-routing-workload
Invocation: invocation.synthetic.0241
Service: support-router
Project or code owner: Customer Operations Platform
Identity: svc-support-router
Organization: Customer Experience Systems
Budget responsibility: CX Automation

Operational confidence

0.91

Output state

Strongly inferred

At or above the 0.80 review threshold

Explanation: Service, deployment, identity, organization, and billing evidence support one leading path.
Time basis: Event-time, synthetic evaluation window
Source health: All enabled synthetic sources healthy
Action eligibility: Decision support

Evidence sources

Provider billing record
Deployment metadata
Service identity
Organization hierarchy

Alternative candidates

Support Experience team, retained as an alternative
Platform Infrastructure, runtime owner only

Truth domains

Observed Inferred Event-time

Evidence and implementation boundary

What the current claim supports

The schema defines which relation types may exist. The attribution engine evaluates eligible candidate relationships; it does not invent new relation types. The current governed aggregation method remains an implementation concern and is not replaced by visual arithmetic.

Edge versus path confidence: each eligible relationship can carry an edge-specific state and confidence. The final path confidence travels with output state, source health, time basis, alternatives, and intended decision. The visual does not invent a formula or imply that a downstream path can exceed a required weaker edge.

Ownership versus allocation: fractional cost allocation is a separate result. It cannot overwrite ownership attribution.

Known limitations

Unknown and unresolved states remain valid outcomes

01An invocation does not need service or project context to remain a valid governed record.
02A valid absent relationship is different from an unknown relationship and must remain distinguishable.
03Edge confidence and path confidence are distinct and cannot be inferred from an unlabeled visual average.

Decision enabled

Determine which ownership relationships are supported, absent, ambiguous, or still unknown before an attributed decision is used.

The graph makes the attribution basis inspectable: a reviewer can see exactly which relationships support the owner path and where the chain stops.