System One

System One profiles connect to an Ollama-compatible POST /v1/systemone endpoint. Add profiles under Connections > LLMs, then use them as conditions in Events > Rules. See the System One API reference for endpoint and model requirements.

Configure a profile

Enter a profile name, base URL, model, and optionally an API key. Stream Pulse appends /v1/systemone to the base URL. Use Test endpoint to send a small yes/no request. The browser contacts the endpoint directly, so the endpoint must permit requests from the Stream Pulse app’s origin (CORS).

A successful test turns the button green with a check mark until you change a setting. Saving a profile that is untested, changed since its last test, or whose last test failed asks for confirmation first; Save anyway still saves it.

API keys are kept in memory only. Re-enter them after restarting; they are not stored locally or included in exports.

System One conditions make real endpoint requests even when action execution is in dry-run mode. Model usage may be billable, and endpoint availability and latency affect event routing.

Add a rule condition

Add a System One condition to a game event rule. Its state template and questions are JSON and support the same `` event templates as actions. System One supports noul (yes/no), choice, and score questions. Question names use letters, numbers, _, ., and -; configure between 1 and 64 questions. Choice criteria need 2–255 options, though individual models may support fewer. Score criteria need 2–10 ordered levels.

This example asks the model whether an event represents a death. The matches list gates the rule on a confident true answer:

{
  "stateTemplate": {
    "event": "",
    "feature": "",
    "data": ""
  },
  "questions": {
    "is_death": {
      "type": "noul",
      "instructions": "Does this event mean the player has died?",
      "criteria": {
        "true": "The event indicates the player died.",
        "false": "The event does not indicate the player died."
      }
    }
  },
  "matches": [
    {
      "question": "is_death",
      "operator": "eq",
      "value": true,
      "minimumConfidence": 0.8
    }
  ]
}

All entries in matches must pass. eq, neq, contains, and numeric comparisons are available. minimumConfidence requires the model’s confidence to meet a threshold; for noul, it uses the larger of the true/false probabilities. probabilityFor and minimumProbability can gate on a named choice, a zero-based score index, or true/false for noul. An empty matches array always passes the condition, but still evaluates and emits the result event.

Decision events

Each successful evaluation emits an event on the virtual System One (LLM) game, with feature decision and the configured decision event name. The event’s data contains the profile and model IDs, typed answers, usage, and a summary of the input event. Add an ordinary rule for that game/event to react to a decision whether or not the original rule’s match expressions passed.

System One conditions are not evaluated on System One decision events, which prevents recursive calls. Request failures are reported in activity and do not match the affected rule. Event payload and model usage are not persisted.