This Glossary provides a quick reference for common terms related to Synapse technical and analytical concepts.
See Power-Up, Advanced.
See Tool, Admin.
See Model, Analytical.
An auth gate (short for “authorization gate”, informally a “gate”) is an object within a Service that may have its own set of permissions.
Short for “automatic addition”. Within Synapse, a feature of node creation where any secondary properties that are derived from a node’s primary property are automatically set when the node is created. Because these secondary properties are based on the node’s primary property (which cannot be changed once set), the secondary properties are read-only.
For example, creating the node
inet:firstname.lastname@example.org will result in the autoadd of the secondary
See also the related concept Depadd.
The Axon is a Synapse Service that provides binary / blob (“file”) storage within the Synapse ecosystem. An Axon indexes binaries based on their SHA-256 hash for deduplication. The default Axon implemenation stores the blobs in an LMDB Slab.
See Tag, Base.
Binary Unique Identifier
See Function, Callable.
In Optic, a column in Tabular display mode that displays a property value from an adjacent or nearby node.
In Optic, a column in Tabular display mode that displays a property value from the specified form.
In Optic, a column in Tabular display mode that displays the timestamps associated with the specified tag. (Technically, Optic displays two columns - one for each of the min / max timestamps, if present).
Column, Tag Glob
In Optic, a column in Tabular display mode that displays any tags that match the specified tag or tag glob pattern.
Short for Comparison Operator.
A symbol or set of symbols used in the Storm language to evaluate Node property values against one or more specified values. Comparison operators can be grouped into standard and extended operators.
Comparison Operator, Standard
The set of common operator symbols used to evaluate (compare) values in Storm. Standard comparison operators include
equal to (
=), greater than (
>), less than (
<), greater than or equal to (
>=), and less than or equal
Comparison Operator, Extended
The set of Storm-specific operator symbols or expressions used to evaluate (compare) values in Storm based on custom or
Storm-specific criteria. Extended comparison operators include regular expression (
~=), time/interval (
*in=), tag (
#), and so on.
See Form, Composite.
See Tool, Console.
In Storm, a constant is a value that cannot be altered during normal execution, i.e., the value is constant.
Within Synapse, a constructor is code that defines how a Property value of a given Type can be constructed to ensure that the value is well-formed for its type. Also known as a Ctor for short. Constructors support Type Normalization and Type Enforcement.
A Cortex is a Synapse Service that implements Synapse’s primary data store (as an individual Hypergraph). Cortex features include scalability, key/value-based node properties, and a Data Model which facilitates normalization.
Within Synapse, cron jobs are used to create scheduled tasks, similar to the Linux/Unix “cron” utility. The task to be executed by the cron job is specified using the Storm query language.
Pronounced “see-tore”. Short for Constructor.
Similar to a traditional Linux or Unix daemon, a Synapse daemon (“dmon”) is a long-running or recurring query or process that runs continuously in the background. A dmon is typically implemented by a Storm Service and may be used for tasks such as processing elements from a Queue. A dmon allows for non-blocking background processing of non-critical tasks. Dmons are persistent and will restart if they exit.
Data Emitter Function
See Model, Data.
Data Model Explorer
Within Synapse, a term typically used with respect to Node creation. A node is deconflictable if, upon node
creation, Synapse can determine whether the node already exists within a Cortex (i.e., the node creation attempt is
deconflicted against existing nodes). For example, on attempting to create the node
inet:fqdn=woot.com Synapse can
deconflict the node by checking whether a node of the same form with the same primary property already exists.
Most primary properties are sufficiently unique to be readily deconflictable. GUID forms (see Form, GUID) require additional considerations for deconfliction. See the guid section of the Storm Reference - Type-Specific Storm Behavior document for additional detail.
Short for “dependent addition”. Within Synapse, when a node’s secondary property is set, if that secondary property is of a type that is also a form, Synapse will automatically create the node with the corresponding primary property value if it does not already exist. (You can look at this as the secondary property value being “dependent on” the existence of the node with the corresponding primary property value.)
For example, creating the node
inet:email@example.com will set (via Autoadd) the
inet:email:domain=mail.somecompany.org. Synapse will automatically create the node
inet:fqdn=mail.somecompany.org as a dependent addition if it does not exist.
(Note that limited recursion will occur between dependent additions (depadds) and automatic additions (autoadds).
inet:fqdn=mail.somecompany.org is created via depadd, Synapse will set (via autoadd)
inet:fqdn:domain=somecompany.org, which will result in the creation (via depadd) of the node
inet:fqdn=somecompany.org if it does not exist, etc.)
See also the related concept Autoadd.
See Property, Derived.
See Edge, Directed.
See Graph, Directed.
Tabular mode, which displays data and tags in tables (rows of results with configurable columns).
Force Graph mode, which projects data into a directed graph-like view of nodes and their interconnections.
Statistics (stats) mode, which automatically summarizes data using histogram (bar) and sunburst charts.
Geospatial mode, which can be used to plot geolocation data on a map projection.
Short for Daemon.
In Synapse, easy permissions (“easy perms” for short) are a simplified means to grant common sets of permissions for a particular object to users or roles. Easy perms specify four levels of access, each with a corresponding integer value:
Deny = 0
Read = 1
Edit = 2
Admin = 3
Edge, Lightweight (Light)
In Synapse, a lightweight (light) edge is a mechanism that links two arbitrary forms via a user-defined verb that describes the linking relationship. Light edges are not forms and so do not support secondary properties or tags. They are meant to simplify performance, representation of data, and Synapse hypergraph navigation for many use cases. Contrast with Form, Edge.
See Column, Embed.
Entity resolution is the process of determining whether different records or sets of data refer to the same real-world entity.
A number of data model elements in Synapse are designed to support entity resolution. For example:
ps:contactnode can capture “a set of observed contact data” for a person (
ps:person) or organization (
ou:org). You can link sets of contact data that you assess represent “the same” entity via their
risk:threatnode can capture “a set of reported data about a threat”. If you assess that multiple sources are reporting on “the same” threat, you can link them to an authoritative threat organization via their
ou:industrynamenode can capture a term used to refer to a commercial industry. You can link variations of a name (e.g., “finance”, “financial”, “financial services”, “banking and finance”) to a single
Extended Comparison Operator
See Form, Extended.
See Property, Extended.
A feed is an ingest API consisting of a set of ingest formats (e.g., file formats, record formats) used to parse records directly into nodes. Feeds are typically used for bulk node creation, such as ingesting data from an external source or system.
See Storm Reference - Filtering for additional detail.
Within Synapse, a subquery filter is a filter that consists of a Storm expression.
See Subquery Filters for additional detail.
Within Synapse, fork may refer to the process of forking a View, or to the forked view itself.
When you fork a view, you create a new, empty, writable Layer on top of the fork’s original view. The writable layer from the original view becomes read-only with respect to the fork. Any changes made within a forked view are made within the new writable layer. These changes can optionally be merged back into the original view (in whole or in part), or discarded. (Note that any view-specific automation, such as triggers, dmons, or cron jobs, are not copied to the forked view. However, depending on the automation, it may be activated if / when data is merged down into the original view.
A form is the definition of an object in the Synapse data model. A form acts as a “template” that specifies how to create an object (Node) within a Cortex. A form consists of (at minimum) a Primary Property and its associated Type. Depending on the form, it may also have various secondary properties with associated types.
A category of form whose primary property is an ordered set of two or more comma-separated typed values. Examples
include DNS A records (
inet:dns:a) and web-based accounts (
See also Form, Edge.
A specialized composite form (Form, Composite) whose primary property consists of two Ndef values. Edge forms can be used to link two arbitrary forms via a generic relationship where additional information needs to be captured about that relationship (i.e., via secondary properties and/or tags). Contrast with Edge, Lightweight (Light).
A custom form added outside of the base Synapse Data Model to represent specialized data. Extended forms can be added with the $lib.model.ext libraries. Note that whenever possible, it is preferable to expand the base Synapse data model to account for novel use cases instead of creating specialized extended forms.
In the Synpase Data Model, a specialized case of a Simple Form whose primary property is a
GUID. The GUID can be either arbitrary or constructed from a specified set of values. GUID forms have
additional considerations as to whether or not they are Deconflictable in Synapse. Examples of GUID
forms include file execution data (e.g.,
inet:file:exec:read) or articles (
In the Synapse Data Model, a category of form whose primary property is a single typed value. Examples
include domains (
inet:fqdn) or hashes (e.g.,
In Storm, a callable function is a “regular” function that is invoked (called) and returns exactly one value.
A callable function must include a
return() statement and must not include the
Function, Data Emitter
In Storm, a data emitter function emits data. The function returns a generator object that can be iterated over.
A data emitter function must include the
emit keyword and must not include a
Function, Node Yielder
In Storm, a node yielder function yields nodes. The function returns a generator object that can be iterated
over. A node yielder function must not include either the
emit keyword or a
See Knowledge, Fused.
See Auth Gate.
Global Default Workspace
Globally Unique Identifier
A graph is a mathematical structure used to model pairwise relations between objects. Graphs consist of vertices (or nodes) that represent objects and edges that connect exactly two vertices in some type of relationship. Nodes and edges in a graph are typically represented by dots or circles connected by lines.
See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.
A directed graph is a Graph where the edges representing relationships between nodes have a “direction”. Given node X and node Y connected by edge E, the relationship is valid for X -> E -> Y but not Y -> E -> X. For example, the relationship “Fred owns bank account #01234567” is valid, but “bank account #01234567 owns Fred” is not. Nodes and edges in a directed graph are typically represented by dots or circles connected by arrows.
See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.
Short for Globally Unique Identifier. Within Synapse, a GUID is a Type specified as a 128-bit value that is unique within a given Cortex. GUIDs are used as primary properties for forms that cannot be uniquely represented by a specific value or set of values.
See Form, GUID.
See Tool, Help.
The Hive is a key/value storage mechanism which is used to persist various data structures required for operating a Synapse Cell.
A hyperedge is an edge within a Hypergraph that can join any number of nodes (vs. a Graph or Directed Graph where an edge joins exactly two nodes). A hyperedge joining an arbitrary number of nodes can be difficult to visualize in flat, two-dimensional space; for this reason hyperedges are often represented as a line or “boundary” encircling a set of nodes, thus “joining” those nodes into a related group.
See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.
A hypergraph is a generalization of a Graph in which an edge can join any number of nodes. If a Directed Graph where edges join exactly two nodes is two-dimensional, then a hypergraph where a Hyperedge can join any number (n-number) of nodes is n-dimensional.
See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.
Short for Identifier. Within Synapse, the hexadecimal representation of a unique identifier (e.g., for a node, a task, a trigger, etc.) The term “identifier” / “iden” is used regardless of how the specific identifier is generated.
See Tool, Ingest.
See Knowledge, Instance.
If a form within the Synapse data model has a “range” of time elements (i.e., an interval such as “first seen”/”last
seen”), the form typically represents fused knowledge – a period of time during which an object, relationship, or
event was known to exist. Forms representing fused knowledge can be thought of as combining n number of instance
inet:whois:email forms are examples of fused
See Instance Knowledge vs. Fused Knowledge for a more detailed discussion.
If a form within the Synapse data model has a specific time element (i.e., a single date/time value), the form
typically represents instance knowledge – a single instance or occurrence of an object, relationship, or event.
inet:whois:rec forms are examples of instance knowledge.
See Instance Knowledge vs. Fused Knowledge for a more detailed discussion.
Within Synapse, a layer is the substrate that contains node data and where permissions enforcement occurs. Viewed another way, a layer is a storage and write permission boundary.
By default, a Cortex has a single layer and a single View, meaning that by default all nodes are stored in one layer and all changes are written to that layer. However, multiple layers can be created for various purposes such as:
separating data from different data sources (e.g., a read-only layer consisting of third-party data and associated tags can be created underneath a “working” layer, so that the third-party data is visible but cannot be modified);
providing users with a personal “scratch space” where they can make changes in their layer without affecting the underlying main Cortex layer; or
segregating data sets that should be visible/accessible to some users but not others.
Layers are closely related to views (see View). The order in which layers are instantiated within a view matters; in a multi-layer view, typically only the topmost layer is writeable by that view’s users, with subsequent (lower) layers read-only. Explicit actions can push upper-layer writes downward (merge) into lower layers.
See Tag, Leaf.
See Storm Reference - Lifting for additional detail.
Lightweight (Light) Edge
A macro is a stored Storm query. Macros support the full range of Storm syntax and features.
Within Synapse, a system or systems used to represent data and/or assertions in a structured manner. A well-designed model allows efficient and meaningful exploration of the data to identify both known and potentially arbitrary or discoverable relationships.
Pronounced “en-deff”. Short for node definition. A node’s Form and associated value
(i.e., <form> = <valu> ) represented as comma-separated elements enclosed in parentheses:
A node is a unique object within a Cortex. Where a Form is a template that defines the
charateristics of a given object, a node is a specific instance of that type of object. For example,
is a form;
inet:fqdn=woot.com is a node.
In Optic, a saved, named Storm query or command (action) that can be executed via a right-click context menu option for specified forms (nodes).
Node data is a named set of structured metadata that may optionally be stored on a node in Synapse. Node data may be used for a variety of purposes. For example, a Power-Up may use node data to cache results returned by a third-party API along with the timestamp when the data was retrieved. If the same API is queried again for the same node within a specific time period, the Power-Up can use the cached node data instead of re-querying the API (helping to prevent using up any API query limits by re-querying the same data).
Node data can be accessed using the node:data type.
Short for “runtime node”. A runt node is a node that does not persist within a Cortex but is created at runtime when
a Cortex is initiated. Runt nodes are commonly used to represent metadata associated with Synapse, such as data model
elements like forms (
syn:form) and properties (
syn:prop) or automation elements like triggers (
or cron jobs (
A storage node (“sode”) is a collection of data for a given node (i.e., the node’s primary property, secondary / universal properties, tags, etc.) that is present in a specific Layer.
Node Yielder Function
Short for “non-runtime safe”. Non-runtsafe refers to the use of variables within Storm. A variable that is
non-runtsafe has a value that may change based on the specific node passing through the Storm pipeline. A variable
whose value is set to a node property, such as
$fqdn = :fqdn is an example of a non-runtsafe variable (i.e., the
value of the secondary property
:fqdn may be different for different nodes, so the value of the variable will be
different based on the specific node being operated on).
Contrast with Runtsafe.
The Synapse user interface (UI), available as part of the commercial Synapse offering.
A package is a set of commands and library code used to implement a Storm Service. When a new Storm service is loaded into a Cortex, the Cortex verifies that the service is legitimate and then requests the service’s packages in order to load any extended Storm commands associated with the service and any library code used to implement the service.
Within Synapse, a permission is a string (such as
node.add) used to control access. A permission is assigned
(granted or revoked) using a Rule.
Access to some objects in Synapse may be controlled by Easy Permissions.
Within Synapse, one of the primary methods for interacting with data in a Cortex. A pivot moves from a set of nodes with one or more properties with specified value(s) to a set of nodes with a property having the same value(s). Compare with Lift, Filter, and Traverse.
See Storm Reference - Pivoting for additional detail.
Power-Ups provide specific add-on capabilities to Synapse. For example, Power-Ups may provide connectivity to external databases or third-party data sources, or enable functionality such as the ability to manage YARA rules, scans, and matches.
The term Power-Up is most commonly used to refer to Vertex-developed packages and services that are available as part of the commercial Synapse offering (only a few Power-Ups are available with open-source Synapse). However, many organizations write their own custom packages and services that may also be referred to as Power-Ups.
Advanced Power-Ups are implemented as Storm services (see Service, Storm). Vertex-developed Advanced Power-Ups are implemented as Docker containers and may require DevOps support and additional resources to deploy.
See Tool, Power-Ups.
See Property, Primary.
See Column, Property.
Within Synapse, a derived property is a secondary property that can be extracted (derived) from a node’s primary
property. For example, the domain
inet:fqdn=www.google.com can be used to derive
inet:fqdn:host=www; the DNS A record
inet:dns:a=(woot.com, 18.104.22.168) can be used to derive
Synapse will automatically set (Autoadd) any secondary properties that can be derived from a node’s primary property. Because derived properties are based on primary property values, derived secondary properties are always read-only (i.e., cannot be modified once set).
Within Synapse, an extended property is a custom property added to an existing form to capture specialized data. For example, extended properties may be added to the data model by a Power-Up in order to record vendor-specific data (such as a “risk” score).
Extended properties can be added with the $lib.model.ext libraries. Note that we strongly recommend that any extended properties be added within a custom namespace; specifically, that property names begin with an underscore and include a vendor or source name (if appropriate) as the first namespace element.
An example of an extended property is the
:_virustotal:reputation score added to some forms to account
for VirusTotal-specific data returned by that Power-Up (e.g.,
Within Synapse, a primary property is the property that defines a given Form in the data model. The primary property of a form must be defined such that the value of that property is unique across all possible instances of that form. Primary properties are always read-only (i.e., cannot be modified once set).
Within Synapse, a relative property is a Secondary Property referenced using only the portion of the
property’s namespace that is relative to the form’s Primary Property. For example,
the full name of the “domain” secondary property of a DNS A record form (
:fqdn is the relative
property / relative property name for that same property.
Within Synapse, secondary properties are optional properties that provide additional detail about a Form. Within the data model, secondary properties may be defined with optional constraints, such as:
Whether the property is read-only once set.
Any normalization (outside of type-specific normalization) that should occur for the property (such as converting a string to all lowercase).
Within Synapse, a universal property is a Secondary Property that is applicable to all forms and may
optionally be set for any form where the property is applicable. For example,
.created is a universal property
whose value is the date/time when the associated node was created in a Cortex.
Within Synapse, a queue is a basic first-in, first-out (FIFO) data structure used to store and serve objects in a classic pub/sub (publish/subscribe) manner. Any primitive (such as a node iden) can be placed into a queue and then consumed from it. Queues can be used (for example) to support out-of-band processing by allowing non-critical tasks to be executed in the background. Queues are persistent; i.e., if a Cortex is restarted, the queue and any objects in the queue are retained.
See Power-Up, Rapid.
See Property, Relative.
Short for “representation”. The repr of a Property defines how the property should be displayed in cases where the display format differs from the storage format. For example, date/time values in Synapse are stored in epoch milliseconds but are displayed in human-friendly “yyyy/mm/dd hh:mm:ss.mmm” format.
See Tool, Research.
In Synapse, a role is used to group users with similar authorization needs. You can assign a set of rules (see Rule) to a role, and grant the role to users who need to perform those actions.
See Tag, Root.
See Node, Runt.
Short for “runtime safe”. Runtsafe refers to the use of variables within Storm. A variable that is runtsafe has a
value that will not change based on the specific node passing through the Storm pipeline. A variable whose value is
explcitly set, such as
$fqdn = woot.com is an example of a runtsafe varaible.
Contrast with Non-Runtsafe.
See Property, Secondary.
Synapse is designed as a modular set of services. Broadly speaking, a service can be thought of as a container used to run an application. We may informally differentiate between a Synapse Service and a Storm Service.
A Storm service is a registerable remote component that can provide packages (Package) and additional APIs to Storm and Storm commands. A service resides on a Telepath API endpoint outside of the Cortex.
When the Cortex is connected to a service, the Cortex queries the endpoint to determine if the service is legitimate and, if so, loads the associated package to implement the service.
An advantage of Storm services (over, say, additional Python modules) is that services can be restarted to reload their service definitions and packages while a Cortex is still running – thus allowing a service to be updated without having to restart the entire Cortex.
See Form, Simple.
A Slab is a core Synapse component which is used for persisting data on disk into a LMDB backed database. The Slab interface offers an asyncio friendly interface to LMDB objects, while allowing users to largely avoid having to handle native transactions themselves.
Short for “storage node”. See Node, Storage.
A splice is an atomic change made to data within a Cortex, such as node creation or deletion, adding or removing a tag, or setting, modifying, or removing a property. All changes within a Cortex may be retrieved as individual splices within the Cortex’s splice log.
See Tool, Spotlight.
Standard Comparison Operator
See Node, Storage.
See Tool, Stories.
Storm is the custom query language analysts use to interact with data in Synapse.
Storm can also be used as a programming language by advanced users and developers, though this level of expertise is not required for normal use. Many of Synapse’s Power-Ups (see Power-Up) are written in Storm.
See Storm Reference - Introduction for additional detail.
Also “Storm Editor Tool”. See Tool, Storm Editor.
See Service, Storm.
Within Synapse, a subquery is a Storm query that is executed inside of another Storm query.
See Storm Reference - Subqueries for additional detail.
See Filter, Subquery.
See Service, Synapse.
Within Synapse, a tag is a label applied to a node that provides additional context about the node. Tags typically represent assessments or judgements about the data represented by the node.
Within Synapse, the lowest (rightmost) tag element in a tag hierarchy. For example, for the tag
baz is the base tag.
The full tag path / longest tag in a given tag hierarchy. For example, for the tag
is the leaf tag.
Within Synapse, the highest (leftmost) tag element in a tag hierarchy. For example, for the tag
foo is the root tag.
See Column, Tag.
Tag Glob Column
See Column, Tag Glob.
In Optic, the Admin Tool provides a unified interface to perform basic management of users, roles, and permissions; views and layers; and triggers and cron jobs.
In Optic, the Console Tool provides a CLI-like interface to Synapse. It can be used to run Storm queries in a manner similar to the Storm CLI (in the community version of Synapse). In Optic the Console Tool is more commonly used to display status, error, warning, and debug messages, or to view help for built-in Storm commands (see Storm Reference - Storm Commands) and / or Storm commands installed by Power-Ups.
In Optic, the central repository for Synapse documentation and assistance. The Help Tool includes the Data Model Explorer, Tag Explorer, documentation for any installed Power-Ups (see Power-Up), links to the public Synapse, Storm, and Optic documents, and version / changelog information.
In Optic, the primary tool used to load structured data in CSV, JSON, or JSONL format into Synapse using Storm. The Ingest Tool can also be used to prototype and test more formal ingest code.
In Optic, the primary tool used to ingest, enrich, explore, visualize, and annotate Synapse data.
Also known as simply “Spotlight”. In Optic, a tool used to load and display PDF or HTML content,
create an associated
media:news node, and easily extract and link relevant indicators or other nodes.
Also known as simply “Stories”. In Optic, a tool used to create, collaborate on, review, and publish finished reports. Stories allows you to integrate data directly from the Research Tool into your report (“Story”).
Tool, Storm Editor
Also known as simply “Storm Editor”. In Optic, a tool used to compose, test, and store Storm
queries (including macros - see Macro). Storm Editor includes a number of integrated development
environment (IDE) features, including syntax highlighting, auto-indenting, and auto-completion (via
ctrl-space) for the names of forms, properties, tags, and libraries.
Within Synapse, one of the primary methods for interacting with data in a Cortex. Traversal refers to navigating the data by crossing (“walking”) a lighweight (light) edge (Edge, Lightweight (Light)) betweeen nodes. Compare with Lift, Pivot, and Filter.
See Traverse (Walk) Light Edges for additional detail.
Within Synapse, a trigger is a Storm query that is executed automatically upon the occurrence of a specified event within a Cortex (such as adding a node or applying a tag). “Trigger” refers collectively to the event and the query fired (“triggered”) by the event.
Within Synapse, a type is the definition of a data element within the data model. A type describes what the element is and enforces how it should look, including how it should be normalized.
Within Synapse, base types include standard types such as integers and strings, as well as common types defined within
or specific to Synapse, including globally unique identifiers (
guid), date/time values (
time), time intervals
ival), and tags (
syn:tag). Many forms within the Synapse data model are built upon (extensions of) a subset
of common types.
Within Synapse, knowledge-domain-specific forms may themselves be specialized types. For example, an IPv4 address
inet:ipv4) is its own specialized type. While an IPv4 address is ultimately stored as an integer, the type has
additional constraints, e.g., IPv4 values must fall within the allowable IPv4 address space.
Type awareness is the feature of the Storm query language that facilitates and simplifies navigation through the Hypergraph when pivoting across nodes. Storm leverages knowledge of the Synapse Data Model (specifically knowledge of the type of each node property) to allow pivoting between primary and secondary properties of the same type across different nodes without the need to explicitly specify the properties involved in the pivot.
Within Synapse, the process by which property values are required to conform to value and format constraints defined
for that Type within the data model before they can be set. Type enforcement helps to limit bad data being
entered in to a Cortex by ensuring values entered make sense for the specified data type (e.g., that an IP address
cannot be set as the value of a property defined as a domain (
inet:fqdn) type, and that the integer value of the
IP falls within the allowable set of values for IP address space).
Within Synapse, the process by which properties of a particular type are standardized and formatted in order to ensure consistency in the data model. Normalization may include processes such as converting user-friendly input into a different format for storage (e.g., converting an IP address entered in dotted-decimal notation to an integer), converting certain string-based values to all lowercase, and so on.
See Property, Universal.
In Synapse, a user is represented by an account in the Cortex. An account is required to authenticate (log in) to the Cortex and is used for authorization (permissions) to access services and perform operations.
In Storm, a variable is an identifier with a value that can be defined and/or changed during normal execution, i.e., the value is variable.
See Storm Reference - Advanced - Variables for a more detailed discussion of variables.
Within Synapse, a view is a ordered set of layers (see Layer) and associated permissions that are used to synthesize nodes from the Cortex, determining both the nodes that are visible to users via that view and where (i.e., in what layer) any changes made by a view’s users are recorded. A default Cortex consists of a single layer and a single view, meaning that by default all nodes are stored in one layer, all changes are written to that layer, and all users have the same visibility (view) into Synapse’s data.
In multi-layer systems, a view consists of the set of layers that should be visible to users of that view, and the order in which the layers should be instantiated for that view. Order matters because typically only the topmost layer is writeable by that view’s users, with subsequent (lower) layers read-only. Explicit actions can push upper-layer writes downward (merge) into lower layers.
In Optic, a Workflow is a customized set of UI elements that provides an intuitive way to perform particular tasks. Workflows may be installed by Synapse Power-Ups (see Power-Up) and give users a more tailored means (compared to the Research Tool or Storm query bar) to work with Power-Up Storm commands or associated analysis tasks.
See Tool, Workflows.
In Optic, a Workspace is a customizable user environment. Users may configure one or more Workspaces; different Workspaces may be designed to support different analysis tasks.
Workspace, Global Default
In Optic, a Workspace that has been pre-configured with various custom settings and distributed for use. A Global Default Workspace can be used to share a set of baseline Workspace customizations with a particular group or team.
See Tool, Workspaces.