Runtime Closed Loop

Namespace: https://ecosystem.ai/ontology/runtime#

Concepts for ecosystem-runtime: score offers, log contacts, accept feedback, and learn.

Sequence


Client → POST /invocations → InvocationResponse (final_result by rank)
       → ContactLog written (uuid)
Client → POST /response (uuid + offer_name) → ResponseFeedback
       → ResponseLog written (response_uuid, embeds ContactLog)

Same uuid ties invocation, contact log, and response.

API classes

Class	Role
`InvocationRequest`	`/invocations` body: `campaign`, `subcampaign`, `customer`, `channel`, `numberOffers`, `paramsJson` (string), optional `debug`
`InvocationResponse`	Return: `uuid`, `final_result`, explore/cache, `in_params`; optional `hasDebug` when `debug` was requested
`InvocationDebug`	Developer diagnostics: `explanations`, `errors`, `config`, `database`, `params` (not persisted in ContactLog)
`InvocationDebugError`	One `debug.errors[]` row: `stage`, `code`, `exception`, `at`, `message`
`InvocationDebugExplanation`	One `debug.explanations[]` row: `code`, `severity`, `title`, `message`, optional `hint`
`FinalResultEntry`	Ranked row: `rank` + slim `OfferResult` + `result_full`
`OfferResult`	Slim offer: `uuid`, `offerName`, scores, cost/price
`PersonalityOfferResult`	Trait-oriented `result_full` (Spend Personality)
`ProductOfferResult`	Product + bandit `result_full` (recommenders)
`ResponseFeedback`	`/response` body: `uuid` + `offers_accepted`
`AcceptedOffer`	Accepted slim offer row

Matching accepted offers: prefer offer_name (also offer / offer_treatment_code).

Logging

Class	Store (typical)	Role
`ContactLog`	`logging.ecosystemruntime`	Invocation log: uuid, predictor, api_params, params, final_result, stats, scoring_data
`ResponseLog`	`logging.ecosystemruntime_response`	Feedback log: uuid, responseUuid, embedsContactLog, response payload
`ServerInfo`	nested	hostname, address, port, version
`InvocationStats`	nested	durations, epsilon, model, error

Links: hasFinalResult, scoringData → open CustomerFeatureDocument; embedsContactLog; hasResponsePayload; respondsTo

Campaign context

Class	Role
`CampaignContext`	Isolated runtime unit (campaign / predictor name)
`GlobalSettings`	Properties: plugins, logging, offer matrix, param lookup, corpora
`FeatureLookupConfig`	Open customer/feature DB lookup
`DynamicEngagementConfig`	Algorithm + contextual variables corpora
`Option`	Options-store arm; `optionKey` joins OfferMatrixEntry
`ScoringParams`	Internal pipeline bag for plugins

Links: hasOfferMatrix (fixed rows), hasFeatureLookup (open docs), hasDynamicEngagement, plugin uses*

Plugins

Class	Config key
`PrePredictPlugin`	`plugin.prescore`
`PostPredictPlugin`	`plugin.postscore`
`RewardPlugin`	`plugin.reward`

Offer Matrix
Customer Feature Lookup
Runtime & Deployment docs
Runtime MCP — ontology tools & agent flow
Ontology for agents — Explorer UI and REST catalog
Examples TTL: /ontology/runtime-examples.ttl

MCP & agent grounding

The runtime exposes its ontology for AI agents via MCP resources and validation tools on POST {RUNTIME}/mcp:

MCP resource	Purpose
`ontology://runtime`	Module summary and entry points
`ontology://runtime/closed-loop`	Canonical agent recipe (markdown)
`ontology://runtime/examples`	Annotated ContactLog / ResponseLog examples
`ontology://runtime/concept/{name}`	Concept card (e.g. `InvocationRequest`)

MCP tool	Purpose
`getClosedLoopRecipe`	JSON workflow: listCampaigns → validate → invoke → validate → response
`lookupRuntimeConcept`	Search concepts by name, label, or related MCP tool
`validateInvokeRequest`	Pre-flight `InvocationRequest` before `invoke`
`validateResponseRequest`	Pre-flight `ResponseFeedback` before `response`

REST mirror: GET /ontology/runtime/* and POST /ontology/runtime/validate/* on the Java runtime. See MCP Support.

Full tables: Runtime Catalog · Concept Index

Download: /ontology/runtime.ttl · shapes: /ontology/runtime-shapes.ttl