Attribution

Definition

Attribution is ownership metadata: tenant, namespace, app, team, user, service, workflow, and agent where available.

Why It Matters

Without attribution, spend can be visible but unactionable. A report may show dollars and tokens, but the team that should fix retry policy or routing is unknown.

Attribution is useful because every field carries provenance. The report can distinguish observed ownership from inferred or missing ownership.

How Blackridge Represents It

EconomicsEvent.attribution carries tenant, namespace, app, team, user, environment, service ID, optional per-field confidence, and conflicts. context_sources records where fields came from.

Implemented attribution sources include environment defaults, identity-token mode, trusted-header mode, framework/request headers, and import fields. Legacy JWT attribution is present in code but existing manual notes it is not the preferred stock path.

Minimum Useful Metadata

Useful attribution starts with stable ownership and workflow context: tenant, application, team, user or service identity, and a workflow/run identifier when the call belongs to a business process. In most deployments, ownership comes from the resolver ladder and workflow context comes from the SDK, so teams do not need to hand-maintain per-request metadata.

Common Mistakes

• Sending only a user ID and no team/app.
• Changing workflow IDs on every retry instead of keeping one logical workflow/run identity.
• Trusting headers from untrusted clients without a proxy boundary.

Related Docs

• Glossary
• Event Schema
• Report Fields