> ## Documentation Index > Fetch the complete documentation index at: https://docs.seynlabs.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > The vocabulary that shows up in every Seyn surface: dashboard, chat, API, and these docs. Everything in Seyn fits into three layers: a **data layer** that records what happened (raw records, events, actors), a **knowledge layer** that records what it means (assertions, projected into rules and libraries), and a **provenance layer** that ties every claim in the second back to evidence in the first. Skim this page once; refer back as needed. ``` DATA LAYER Raw Record ──▶ Normalized Event ──▶ Actor Identity │ │ PROVENANCE └── every hop recorded ──┐ ▼ KNOWLEDGE LAYER Assertions (the substrate, append-only) │ projected into ▼ Process Rules · Knowledge Library (versioned views) ``` *** ## Raw Record A **raw record** is a single piece of data exactly as Seyn ingested it from a source system: one Teams/Slack message, one email, one SharePoint document, one CRM row. Each records which [connector](/platform/connectors) brought it in and is deduplicated by content hash, so re-syncs never create duplicates. You rarely list raw records directly. They're the bottom of every [provenance](/platform/provenance) chain. ## Normalized Event Raw payloads are heterogeneous; **normalized events** are not. Every event answers the same four questions: *who* (actor), *did what* (action), *to which entity*, *when* (timestamp), plus a pointer back to the raw records it came from. This common schema is what makes cross-system analysis possible. Extraction reasons over events, never over source-specific formats. Details in [Events](/platform/events). ## Actor Identity The same human is `j.smith@acme.com` in email, `Jane Smith` in Teams/Slack, and `JS` in a filename convention. **Actor identities** are canonical people, with identities merged across systems so that "who does this step" has one answer instead of three. ## Knowledge Assertion The atom of Seyn's knowledge. An **assertion** is one append-only claim with a precise shape: a **subject** (a process, a step, an actor, a tool, an entity) and a **typed predicate** about it (a policy, an SLA, a step ordering, a role, a tool usage, a workaround). Not prose; structure. *"About the contract step of the deal pipeline, we claim: deals above \$30M require CEO approval."* Each assertion carries: * **Who asserted it.** The extraction pipeline, a structured interview, a human edit, or an import: all first-class, all distinguishable forever. * **Why.** Reasoning metadata appropriate to the source: how often the pattern was observed and how many counter-examples exist for extracted claims; how confident the interviewee sounded for interviewed ones. * **When.** Validity intervals plus supersession links. Assertions are never edited; new ones supersede old ones, and both timelines survive. Assertions are the substrate. Rules, libraries, chat answers, and query results are views over it. See [Knowledge](/platform/knowledge#assertions-the-unit-of-knowledge). ## Process & Process Rule A **process** is a named sequence of steps an entity flows through: `loan-approval`, `deal-pipeline`, `support-ticket-resolution`. A **process rule** is the readable unit you work with day to day: one statement, projected from the underlying assertions, pinned to a process and optionally a step. > Deals above \$30M or flagged by finance require CEO-level approval before advancing to contract stage. Every rule carries: | Field | Meaning | | --------------- | ----------------------------------------------------- | | `id` | UUID. The handle you use in every other call. | | `description` | The plain-English sentence the pipeline produced. | | `processId` | Which process the rule belongs to. | | `appliesAtStep` | Which step it kicks in at, or `null` if process-wide. | | `confidence` | 0–1. How confident the model is in the rule. | | `frequency` | 0–1. How often the supporting events appear. | | `reviewStatus` | Whether a human has validated it. See below. | | `condition` | A structured representation of the rule's logic. | | `evidence` | Links into the provenance chain. | ## Knowledge Library A **knowledge library** is a versioned view of everything Seyn knows about your organisation. Each extraction run produces a new version; older versions stay accessible. Libraries are `draft`, `active`, or `archived`; queries read the active one. Because libraries are projections over an append-only substrate, versioning goes beyond snapshots: you can read the library **as of any timestamp**, tag **named versions** ("post-onboarding-v1"), and **revert** to a tagged state without losing the history of what came after. ## Knowledge Edit Humans change knowledge through **knowledge edits**: a proposed mutation (new assertions, retractions, supersessions) that is reviewed and then applied. The instruction, the proposal, and exactly which assertions it touched are all recorded. Even the act of correcting Seyn leaves a receipt. ## Provenance **Provenance is Seyn's audit chain**: the answer to *"where did this claim come from, and what's the evidence?"* For an extracted rule, four hops: ``` Rule └─ Inference Log (the specific LLM call: model, prompt version, tokens, timestamp) └─ Normalized Events (the structured events the model reasoned over) └─ Raw Records (the original source data, verbatim) ``` Provenance follows the source. A fact extracted from message content cites the exact message and text span; an interviewed claim cites the transcript turn; a human edit cites the editor and instruction. The chain is enforced in the database itself; evidence cannot be deleted while a claim depends on it. [Provenance](/platform/provenance) covers it in depth. ## Inference Log Every LLM call in Seyn goes through one central inference function and lands in the **inference log**: model, versioned prompt, token counts, latency, and the exact input events. It's both the middle link of provenance and the platform's cost and quality audit trail. See [Observability](/platform/observability). ## Entity People, tools, deals, documents: **entities** are first-class nodes linked to the assertions that mention them. The entity graph is what powers "what's connected to this?" traversal in [querying](/platform/query) and the `get_entity_graph` [MCP tool](/platform/mcp): start from a deal, walk to the people who touched it, the tools involved, and the claims about each. ## Review Status The `reviewStatus` field on rules tracks whether a human has validated the model's output: | Value | Meaning | | ----------- | --------------------------------------------------------------- | | `inferred` | The pipeline produced it; no human has looked yet. The default. | | `confirmed` | A human reviewed and signed off as-is. | | `modified` | A human edited the rule and accepted the modified version. | | `rejected` | A human reviewed and rejected it. Wrong or noise. | Production integrations usually filter to `confirmed` (often plus `modified`). Combining `reviewStatus` with `confidence` is a much better signal than either alone. ## Confidence A 0–1 score indicating how confident the model is in a claim. Treat it as a heuristic, not a probability: * `>0.85`: high; usually reliable enough to act on. * `0.6–0.85`: medium; worth eyeballing. * `<0.6`: low; require human review. ## Pattern Metrics Aggregate analytics computed by SQL over the event data, not by LLMs: stage velocity (median and p90 days per stage), pipeline distribution, kill precursors, quarterly trends, per-actor patterns. Designed for BI tools; pulled via [`client.patterns.metrics()`](/sdk-reference#patterns-metrics). *** ## Related How the layers fit together and where each concept lives. The substrate, projections, and indexes in depth.