# Start with the operational decision—not another dashboard.

> Trinetra correlates support signals into a role-scoped brief and generated Decision Cards. Each card frames the issue, evidence, impact, recommendation, proposed owner role, deadline, and confidence.

## Key Specifications
- **Target Audience:** Support/CX, operations, and technology leadership
- **Primary Inquiry:** What changed, why does it matter, and what should happen next?

## Core Architecture & Mechanism
### 1. Observe
Query tenant-scoped operational and quality evidence already ingested into OpenOS.

### 2. Correlate
Connect repeated patterns across containment, queues, SLA, assignment, quality, and provider state.

### 3. Frame
Generate a Decision Card with issue, impact, evidence, assumptions, recommendation, confidence, owner role, and deadline.

### 4. Operationalize
Convert a selected recommendation into a durable task with a named assignee and lifecycle status.

## Frequently Asked Questions
### Q: Is a Decision Card another alert?
A: No. An alert says something happened. A Decision Card frames what requires a decision, the supporting evidence, expected impact, recommendation, proposed owner role, deadline, and confidence.

### Q: How does a card become owned work?
A: A leader selects the recommendation and converts it into a managed task. That task holds the named assignee and lifecycle status.

### Q: Can leaders ask their own questions?
A: Yes. Natural language is an interface to the governed intelligence layer and its tenant-scoped evidence.

## Claim Boundaries
- A Decision Card is a generated decision artifact, not itself the durable workflow record.
- Owner role and deadline are part of the decision frame; named assignment and status belong to managed work.
- Trinetra queries evidence ingested into OpenOS; it is not presented as live federation across every external system.
- Critical actions use the controls available in the supported workflow and provider path.

---
Canonical Reference: https://www.openost.com/decision-agents