Situations

The fundamental unit of operational work in Qorpera is a situation requiring a decision. This distinction is load-bearing. Workflow automation executes predefined sequences (“when X happens, do Y”). Decision intelligence operates at a higher level: detect that a situation exists, assemble relevant context from across all connected tools, reason about what action is appropriate, and propose.

A situation is not a single notification. It is a pattern composed of signals from multiple systems — an overdue invoice, two unanswered reminders, a renewal in 60 days — that together justify a concrete action.

Two detection methods

Property-based detection runs on a 5-minute cron. Situation types with mode: structured, mode: natural, or mode: hybrid scan entity properties for predefined patterns — overdue invoices, stalling deals, missing follow-ups. Natural-language modes use an LLM-generated structured pre-filter that the audit loop compares against full LLM detection and regenerates when drift is detected.

Content-based detection evaluates communications in real time. The wiki activity pipeline writes activity summaries to person and domain pages; when new activity is assessed as potentially triggering a situation, it routes through the content-detection pipeline with full page context. This catches commitment language, escalation patterns, and action items that no structured rule could catch.

Situation types

Each situation type has configurable detection logic, department scoping, priority weighting, and an archetype classification — a canonical taxonomy of recurring business situation categories that enables cross-operator intelligence transfer.

Admins define situation types per department during onboarding and can refine them at any time. Members only see situations scoped to their departments.

Situation lifecycle

A detected situation creates a situation_instance wiki page, dispatches the reasoning engine, and surfaces in My Work once the action plan is drafted. From there:

• You review the situation, supporting signals, and proposed action plan.
• You approve, edit, or reject.
• Approved actions execute via connector write-back; results write back to the wiki page.
• The full lifecycle — evidence, reasoning, plan, execution, outcome — lives on one page, auditable in full.

Auto-resolution

Open situations auto-resolve when contradicting events arrive — e.g. an overdue-invoice situation closes the moment Stripe reports payment. You don’t have to close what reality already closed.