A request through the platform

Consider the support-triage application in the pipeline walkthrough. Its illustrative route accepts a support request and returns a classified queue record. The path below explains the managed runtime behind that example; it is not a shared demo endpoint.

sequenceDiagram
  participant Client as Application client
  participant Edge as Authenticated edge
  participant Executor as Pipeline executor
  participant Engine as Data engine
  Client->>Edge: Submit support request with credential
  Edge->>Edge: Resolve caller and route
  Edge->>Executor: Dispatch pipeline with verified identity
  Executor->>Executor: Decode and classify request
  Executor->>Engine: Write typed queue record with caller scope
  Engine-->>Executor: Write result
  Executor-->>Edge: Application response
  Edge-->>Client: Accepted record or error

1. Resolve identity and route

The edge receives the request, authenticates the caller for the route, and resolves the published pipeline. A URL alone grants no access. The caller's identity travels with the execution request so downstream data access can apply the appropriate ownership and permission checks.

The pipeline manifest connects the HTTP method and path to execution stages and required capabilities. Redgold publishes this mapping as part of the managed application. You do not need to run a separate web server for each transform. See authentication and the pipeline preview for supported public contracts.

2. Execute application behavior

The executor runs the declared pipeline. Built-in operators handle supported data operations; registered transforms supply application-specific behavior. In this example, the Rust function adds category and priority to the submitted record. The edge relays the response and runs no application handler code.

A model call or external integration is an additional dependency only when the application explicitly uses it. The support example's keyword classifier does not need a model. Adding one introduces provider latency, errors and usage into the application contract; tests should cover those outcomes too.

3. Persist the result

The data engine is the managed boundary for durable writes and scoped reads. The support request becomes a typed queue record in its provisioned dataset. Native schema values use canonical CBOR at platform boundaries; the public request and response encoding follows the particular route's API contract. Clients should not infer that every HTTP endpoint accepts CBOR.

Storage combines a hot tier for recent activity with columnar storage for larger historical reads. The application works against its dataset and schema contract; Redgold operates the storage tiers. Data and pipelines explains the underlying model.

Record identity matters when retrying a submission. A stable request id helps an application implement duplicate handling, but does not by itself guarantee idempotence. Define and test what a second submission does before automatically retrying writes.

4. Return and verify

A successful application response must mean what the route promises. For this example, compare the returned id, category and priority with the documented fixture, then use an authorized read if acceptance requires confirming storage. A healthy service alone does not establish that classification is correct.

Bring that evidence to the managed support workflow or the originating issue. Redgold investigates service execution and rollout state; the application owner confirms intended behavior. Continue with managed deployment for the path that changes the running implementation.