syris-docsv3.0.1
Documentation

What is SYRIS?

Next

SYRIS is a single-user, always-on automation and orchestration control plane.

SYRIS is a single-user, always-on automation control plane — not a chatbot.

SYRIS is not a chat bot. It is a personal operating system for automation and orchestration.

It continuously ingests stimuli from multiple channels, normalises them into a versioned MessageEvent, routes them deterministically (rules-first, LLM as fallback), and executes actions through a capability- and policy-gated tool runtime. Everything is traceable end-to-end via trace_id and queryable via API.

Goals

SYRIS is designed to be:

  • Always-on, restart-resilient: resumes safely after crashes and restarts with no duplicate side effects.
  • Operator-friendly: the operator can always answer "what is it doing and why?" without reading logs.
  • Proactive: timers, alarms, schedules, watchers, and rules initiate actions without user prompting.
  • Safe by default: autonomy levels, confirmation gates, dry-run previews, and least-privilege scopes.
  • Observable by design: append-only audit events and queryable projections feed the dashboard API.

What SYRIS does

SYRIS coordinates:

  • Home/IoT automation: Home Assistant and device control, with anti-flap and quiet-hours policies.
  • Timers, alarms, and schedules: first-class, persistent, visible, and operator-controllable.
  • Rules engine: IFTTT-style rules that trigger workflows via events — auditable and debounced.
  • Task orchestration: multi-step workflows with checkpoints, retries, pause/resume, and cancellation.
  • Integrations + tools: adapters conforming to strict interfaces with declared capabilities and scopes.
  • System awareness: a queryable system state surface covering tasks, queues, schedules, health, and autonomy.

What SYRIS is not

  • Multi-user or multi-tenant.
  • A social conversation agent or persistent chat memory.
  • A distributed microservice platform.
  • A dashboard UI product — SYRIS designs the API surfaces and state model; UI is out of scope.

Design philosophy

SYRIS optimises for, in priority order:

  • Correctness > cleverness
  • Traceability > throughput
  • Deterministic fast paths > LLM everywhere
  • Modular monolith > microservices
  • Idempotency by default > best-effort retries
  • APIs for everything > "check logs"

The core loop

  1. A stimulus arrives → ingested by an inbound adapter
  2. Normaliser produces a MessageEvent and emits event.ingested
  3. Router decides execution lane:
    • Fast lane: execute immediately via tool runtime (bounded latency)
    • Task lane: create or resume a checkpointed Task
    • Gated lane: create an Approval and block until the operator responds
  4. Tools execute with idempotency key enforcement and audit emission
  5. Every stage emits AuditEvent records queryable by trace_id

See architecture/pipeline for the full stage-by-stage breakdown.

Related