Runtime Context
Runtime context is how SCHEMABOUND keeps execution grounded in the real application state that surrounds a request. It gives clients and services a public way to attach stable metadata before validation and execution begin.
Why Runtime Context Matters
Runtime context helps SCHEMABOUND answer practical questions such as:
- which tool or product surface initiated this request
- which user or organization the request belongs to
- which domain tags or table scopes matter for this execution
- which runtime augmentation should be applied before downstream work continues
Without that context, a request may still be valid at the protocol level but incomplete from a product and governance perspective.
Runtime Augmentation
Runtime augmentation is the public mechanism for selecting additional execution context before a request is evaluated.
Clients can use:
x-schemabound-runtime-augmentation-idwhen they already know the specific augmentation identifierx-schemabound-runtime-augmentation-keywhen they want to reference a stable application-facing key
Additional headers help SCHEMABOUND match the right augmentation and preserve the meaning of the request:
x-schemabound-tool-namex-schemabound-tool-intentx-schemabound-user-idx-schemabound-organization-idx-schemabound-domain-tagsx-schemabound-table-names
Distributed Tracing Headers
Two additional headers carry W3C trace-context identifiers for distributed tracing
correlation. When present, these values are propagated into every AuditEventEnvelope
and appear as metadata.trace_uid and metadata.span_uid in every OCSF audit record.
| Header | Purpose |
|---|---|
x-schemabound-trace-id | W3C trace ID — identifies the distributed trace this request belongs to |
x-schemabound-span-id | W3C span ID — identifies the current operation within the trace |
Send these headers when your upstream instrumentation (OpenTelemetry, Jaeger, or similar) already generates trace context. SCHEMABOUND will propagate them through execution events so audit records and OTLP spans can be joined in your observability platform.
What Clients Should Send
Send the smallest stable set of metadata that explains why the request exists and which business boundary it belongs to.
Good examples include:
- the name of the calling product surface or tool
- the user or service identity associated with the request
- the tenant or organization boundary
- domain tags that explain business meaning
- table or resource hints when the execution path depends on them
What SCHEMABOUND Emits
SCHEMABOUND emits resolved augmentation identity into normal query and runtime events so downstream systems can observe which public context was selected.
Sensitive rendered content is intentionally separated from generic event metadata and reserved for dedicated audit handling.
Integration Guidance
Use runtime context when you want SCHEMABOUND behavior to stay aligned with application intent rather than just raw transport details.
Typical uses include:
- attaching product identity in a multi-surface application
- carrying organization context through service-to-service calls
- selecting augmentation rules for automation or assistant workflows
- keeping audit and observability signals consistent across clients