GraphHub onboarding and glossary
A friendly reference for graph concepts, analytics vocabulary, access rules, subscription proposal terms, and the first steps needed to turn raw data into a useful graph workspace.
Start with docs or demos
Use public docs, the glossary, and public demo graphs to understand the workflow before creating or importing anything.
Create a graph
Choose whether the graph belongs to you or an organization, then set its public or private visibility. Plan limits are checked against that owner.
Define schemas
Schemas describe which node and edge types exist, which properties they have, and how records should be identified.
Import or create data
Add nodes and relationships manually, import node and edge CSV files, or use advanced import when one row needs to create several connected records.
Explore the workspace
Use the visual graph workspace to inspect relationships, filter labels, save workspace views, and focus on the part of the graph that matters.
Create Data Views
Turn graph traversals into reusable joined tables before building analyses, dashboards, reports, or public read-only views.
Build analyses
Saved analyses define what should be counted, grouped, filtered, or compared. Charts and matrices are just presentations.
Set access and security
Manage graph roles, organization members, public sharing, MFA requirements, sessions, and audit history before inviting collaborators.
Publish insight
Use dashboards for live summaries, report snapshots for frozen results, schedules for recurring snapshots, and PDF exports when the plan allows them.
Check subscription proposal limits
Review the proposal tier matrix to see which capabilities are intended for Free, Pro, Team, and Enterprise before depending on larger limits.
Glossary
Search definitions when a feature name feels too technical. These explanations are intentionally practical rather than academic.
Graph
A workspace of connected data.
In GraphHub, a graph is also a tenant: it contains its own schemas, Neo4j data, access rules, dashboard, analyses, and reports.
Example: A graph for people, cars, houses, and ownership relationships.Node
A thing in the graph.
Nodes usually represent objects or entities: a person, company, car, house, city, document, or transaction.
Example: Person, Car, House.Edge
A relationship between two nodes.
Edges explain how nodes are connected. They may also have properties, but many useful edges only need a type.
Example: Person -HAS-> Car or Person -KNOWS-> Person.Schema
The contract for a node or edge type.
A schema defines the label, properties, required fields, identity fields, display labels, and allowed edge endpoints.
Example: Person has id, first_name, and last_name.Identity field
A property used to find one specific record.
Identity fields are used during updates, deletes, and edge imports. They should be stable and unique within a schema.
Example: Car.plates or Person.id.Label template
A human-readable display name built from properties.
Label templates make dropdowns and graph nodes readable. They are not a replacement for a true identity field.
Example: {first_name} {last_name}.Tenant
The boundary that keeps one graph's data separate.
GraphHub treats each graph as the practical tenant boundary. Mongo stores definitions and Neo4j stores scoped graph data.
Example: Two organizations may both have a Person schema without mixing records.Public graph
A graph that anonymous visitors can inspect in read-only mode.
Public graphs can appear on public profiles and organization pages. They still respect graph-scoped data boundaries and expose only public read paths.
Example: A demo graph published from an organization profile.Private graph
A graph that requires explicit access.
Private graphs are visible only to owners and members with a role. Subscription tiers can limit how many private graphs an owner may keep.
Example: A customer operations graph restricted to one team.Graph role
A permission level assigned directly on a graph.
Graph roles control whether a user can view, edit, manage collaborators, change MFA requirements, or delete the graph.
Example: viewer, editor, admin, or owner.Organization member
A user who belongs to an organization workspace.
Organization members can access organization-owned resources according to their organization role and any graph-level rules.
Example: An admin invites a teammate as a member.MFA policy
A rule that requires multi-factor authentication before access.
A graph or organization can require MFA. Users must enable and satisfy MFA before opening protected resources.
Example: Require MFA for every graph owned by a regulated organization.Audit log
A record of important access and configuration events.
Audit logs help track who changed graph settings, membership, security requirements, or other sensitive state.
Example: A record that an admin enabled MFA for a graph.Advanced import
An import mode for denormalized CSV files.
Advanced import lets one spreadsheet row create or update multiple nodes and relationships after mapping columns to schema fields.
Example: One row creates a Person, House, Car, and ownership edges.Data View
A reusable joined table generated from graph data.
A Data View starts from a base node type and adds columns from properties, related nodes, or relationship aggregations.
Example: A Person table with owned cars and household location.Saved analysis
A reusable analysis configuration.
Saved analyses store the dataset, filters, grouping, metrics, and default presentation. They do not store live results.
Example: Count cars grouped by make.Dataset
The data source used by an analysis.
A dataset can be nodes, edges, or a graph pattern. It defines what records are available before filters and grouping.
Example: All Car nodes or Person -HAS-> Car relationships.Filter
A condition that narrows down records.
Filters answer 'which records should be included?' before the analysis counts, groups, or calculates anything.
Example: Car.make is Audi or Mercedes-Benz.Grouping
Splitting results into categories.
Grouping answers 'count or calculate separately for each value of this field or category'.
Example: Group cars by make.Bucket
A range used to group numeric values.
Bucketing turns many numeric values into fewer readable ranges, often for histograms or summary charts.
Example: 0-5000, 5001-10000, 10001-15000.Metric
The value an analysis calculates.
Metrics are the numbers shown in tables, charts, cards, and matrix cells.
Example: Count, sum, average, minimum, maximum.Average
The sum of values divided by how many values there are.
Average is easy to understand, but it can be strongly affected by very large or very small outliers.
Example: Salaries 10, 10, and 100 have an average of 40.Median
The middle value after sorting values.
Median is often better than average when outliers would distort the story. Half the values are below it and half are above it.
Example: Salaries 10, 10, and 100 have a median of 10.Percentile
A value below which a percentage of records falls.
Percentiles are useful when you need distribution-aware thresholds rather than one central value.
Example: The 90th percentile means 90% of values are at or below that value.Variance
How spread out values are around the average.
Variance is useful statistically, but it is less intuitive because it uses squared units.
Example: Two groups can have the same average but very different variance.Standard deviation
A more readable measure of spread than variance.
Standard deviation is the square root of variance. It tells how much values typically differ from the average.
Example: Higher standard deviation means values are more scattered.Matrix
A two-dimensional table of intersections.
A matrix compares one dimension against another and shows a metric in each cell.
Example: Person pay level x Car make = count.Traversal
Following relationships outward from a selected node.
Traversal is useful when the question starts with one anchor record and asks what is connected to it within a controlled number of hops.
Example: Show services, APIs, and databases connected to one application.Anchor node
The starting record for a traversal analysis.
The anchor keeps the analysis focused. Instead of showing every matching node in the graph, GraphHub keeps only records connected to this starting point.
Example: Start from Application = Customer Portal.Hop
One relationship step away from a node.
Hop limits prevent traversal analyses from expanding too far. One hop means direct neighbors, two hops includes neighbors of neighbors.
Example: Application -DEPENDS_ON-> Service is one hop.Outlier
A value that stands unusually far from the rest.
Outliers are worth checking because they can reveal real anomalies, data-entry mistakes, or special cases that should not drive averages.
Example: One service with 500 incidents when most services have fewer than 10.Correlation
How strongly two numeric values move together.
Correlation helps spot relationships between measures, but it does not prove that one value causes the other.
Example: Higher incident count may correlate with higher security finding count.Bar chart
A clean comparison of categories.
Bar charts are the safest default when you want to compare counts, sums, averages, or other metrics across named groups.
Example: Incidents by department or services by vendor.Stacked bar chart
Category totals split into colored segments.
Stacked bars are great when both the total and the composition matter. Avoid them when there are too many series or tiny segments.
Example: Incidents by month stacked by severity.Line chart
A trend across ordered values.
Line charts work best for time, ordered stages, or any sequence where movement from left to right matters.
Example: Open incidents per week by severity.Pie chart
A part-of-whole view for a small number of slices.
Pie charts are useful for quick proportions, but they become hard to read with many categories or similar-sized slices.
Example: Share of services by lifecycle status.Radar chart
A profile across several comparable dimensions.
Radar charts are best for comparing a few entities across the same set of metrics. They are not ideal for precise value reading.
Example: Compare teams by reliability, security, delivery, and ownership scores.Scatter / bubble chart
A relationship between two numeric axes.
Scatter charts reveal clusters, gaps, and correlation. Bubble size can add a third measure when the story needs it.
Example: Services plotted by incident count and security findings, sized by repository count.Histogram
A distribution of numeric values in ranges.
Histograms answer how values are spread, where most records sit, and whether the distribution has long tails or gaps.
Example: Applications grouped by monthly cost buckets.Tree chart
A hierarchy shown as parent-child branches.
Tree charts are useful when the data has natural levels, such as organization structures, ownership chains, or dependency hierarchies.
Example: Department -> Team -> Application -> Service.Treemap chart
A hierarchical part-of-whole view using rectangles.
Treemaps show how much each branch contributes to the whole. They are useful when proportions matter more than reading every relationship line.
Example: Department -> Team -> Application sized by incident count.Icicle chart
A layered hierarchy shown as stacked bands.
Icicle charts make hierarchical decomposition easy to scan from parent level to child level. They work well for ownership, cost, risk, and dependency breakdowns.
Example: Business unit -> Team -> Service -> API sized by usage.Sunburst chart
A radial hierarchy for part-of-whole exploration.
Sunburst charts show hierarchy as concentric rings. They are expressive for dashboards and reports, but labels can become dense with many small segments.
Example: Severity -> Asset type -> Owner team sized by finding count.Heatmap
A matrix where color intensity carries meaning.
Heatmaps make dense cross-tab results easier to scan. Stronger colors draw attention to high counts, risks, or concentrations.
Example: Application x cloud region with deployment count.Metric card
One important number shown prominently.
Metric cards work well on dashboards when the user needs a quick status check before drilling into charts or tables.
Example: Open critical incidents: 7.Table
Structured rows when exact values matter.
Tables are best when users need to inspect details, sort records, compare exact numbers, or use the result as a report appendix.
Example: Top 20 services by incident count.Graph workspace
An interactive network view of nodes and edges.
The workspace is ideal for exploration, debugging connections, and understanding local context around selected records. It is not a replacement for aggregated analytics.
Example: Inspect all technical dependencies around one application.Dashboard
A live overview made from saved analyses.
Dashboards are useful for everyday monitoring. They refresh from current graph data.
Example: A graph dashboard with count cards, charts, and a matrix.Report snapshot
A frozen report generated at one moment.
Snapshots store the report output, not just the template. PDF exports should always come from snapshots.
Example: Monthly ownership report generated on July 14, 2026.Report schedule
A rule that generates report snapshots automatically.
A schedule stores weekdays, local time, timezone, and enabled status. GraphHub calculates the next run and creates a new snapshot when that moment is due.
Example: Morning Financial Summary every Monday-Friday at 08:00 Europe/Stockholm.Scheduled snapshot
A report snapshot created by a schedule instead of a person.
Scheduled snapshots use the latest report template and live graph data at execution time. They are stored like manual snapshots after generation.
Example: A daily operations snapshot generated automatically before the morning standup.PDF export
A downloadable document rendered from a stored snapshot.
PDF export should come from a snapshot, not directly from live data. This keeps the exported file consistent with what was generated at that time.
Example: Download last Friday's generated incident report as PDF.Subscription proposal
The proposed packaging model for capabilities and limits.
The public docs describe Free, Pro, Team, and Enterprise as proposal tiers. They intentionally list capabilities and restrictions without prices.
Example: Team includes organization member invitations and scheduled reports.Billing owner
The user or organization whose plan is checked.
GraphHub evaluates limits against the owner of a graph or resource. A personal graph uses the user owner; an organization graph uses the organization owner.
Example: A Team plan on an organization affects graphs owned by that organization.Entitlement
A decision about whether a plan allows an action.
Entitlements check plan status, feature flags, current usage, and enforcement mode before actions such as creating graphs, exporting PDFs, or inviting members.
Example: Creating a scheduled report requires a plan where scheduled reports are included.Enforcement mode
Controls whether billing denials block actions.
Monitor mode evaluates limits but allows actions. Enforce mode returns a plan-limit error when a plan is inactive or a limit is reached.
Example: Enforce mode blocks a PDF export after the monthly limit.Usage counter
A period-based count used for monthly limits.
Usage counters store values by owner, counter key, and YYYY-MM period. PDF exports use this mechanism for monthly limits.
Example: pdf_exports for 2026-08 counts successful PDF exports this month.Plan limit
A maximum capability allowed by a subscription tier.
Limits include graph counts, private graph counts, nodes per graph, relationships per graph, data views, reports, scheduled reports, members, and PDF exports.
Example: Free allows one private graph and a small monthly PDF export quota.