Core Concepts

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 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 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.

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.

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 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.

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 and the get_entity_graph MCP tool: 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().

Architecture

How the layers fit together and where each concept lives.

Knowledge

The substrate, projections, and indexes in depth.

​Raw Record

​Normalized Event

​Actor Identity

​Knowledge Assertion

​Process & Process Rule

​Knowledge Library

​Knowledge Edit

​Provenance

​Inference Log

​Entity

​Review Status

​Confidence

​Pattern Metrics

​Related