What node types does Graphory support?

Graphory uses six generic node types that cover any domain: Person, Organization, Activity, Asset, Account, and Thread. Industry-specific flavor is expressed as properties such as subtype, not as new node types. Identifier is a structural type used for email addresses, phone numbers, and handles.

Can I add custom edge types?

No. The edge vocabulary is fixed so that every graph across every organization speaks the same language. To express a more specific relationship, attach properties to the existing edge (for example, a subtype property) rather than inventing a new edge name.

How do I see the live schema?

Call the describe_schema MCP tool or GET /schema on the Graph API. This returns the node types, edge names, and tier configuration that your organization's agent actually sees at runtime. This documentation is the narrative reference; the API is authoritative.

Ontology

Graphory's knowledge graph is built on a small, deliberately fixed vocabulary: six generic node types and a curated set of edge names. Industry nuance lives in properties, not in new types. This page is the narrative reference. The authoritative version is whatever describe_schema returns for your org.

Principles

Industry-agnostic. The six node types cover any domain. A medical chart, a construction invoice, and a podcast transcript all land in the same shape.
Subtype as property, not as type. An invoice is an Activity with subtype: "invoice". A warehouse is an Asset with subtype: "facility". New node types are not added per customer.
Accumulating ontology. User corrections become rules. Every fix improves extraction for every org on the platform, without leaking the underlying data.
Deterministic extraction. Types and edges are assigned by code reading structured frontmatter. No LLM guesses what is a Person versus an Organization.

Node types

Six generic types cover the full entity space. Capitalized names are canonical and case-sensitive in the schema.

Type	Definition	Examples
`Person`	Any individual.	Employee, customer, contact, founder, candidate, author.
`Organization`	Any company, team, agency, or group.	Customer company, vendor, agency, internal team, trade group.
`Activity`	Any event or action that occurs at a point in time.	Email sent, meeting held, invoice issued, transaction booked, deployment shipped.
`Asset`	Any document, file, or resource.	Contract PDF, video, spreadsheet, Notion page, physical property, product SKU.
`Account`	Any account, project, or deal.	Customer account, sales opportunity, project engagement, bank account, ad account.
`Thread`	A conversation or sequence of related messages.	Email thread, Slack channel conversation, support ticket, chat session.

Identifier is a structural type used to attach stable keys such as email addresses, phone numbers, and external handles to a Person or Organization. It exists at the ontology level for identity resolution and is usually hidden from user-facing views.

At runtime, the schema also exposes a few operational types that arise from how the data is built:

Business represents the owning business entity for a sub-graph when an org has multiple. It behaves like a scoped Organization.
Contact is a resolved, identity-merged view of one or more Person nodes plus their Identifiers.
Community is a cluster produced by community detection, used by discovery tools to suggest latent connections.

These appear in the operational schema returned by describe_schema but are not part of what you create directly. Writes flow into the six generic types; operational types are derived.

Edge vocabulary

Every edge is directional, typed, and carries provenance plus a confidence score. The vocabulary is fixed. To express a more specific relationship, set properties on the existing edge rather than inventing a new name.

Structural

Edge	Meaning
`has`	Containment or ownership between two graph objects (an `Account` has an `Asset`, a `Thread` has an `Activity`).
`uses`	One entity uses or depends on another (a `Person` uses an `Asset`).
`attached_to`	An `Asset` is attached to an `Activity` or `Thread` (for example, a file on an email).
`shared_with`	An `Asset` was shared with a `Person` or `Organization`.

Employment

Edge	Meaning
`works_for`	A `Person` is employed by an `Organization`.
`assigned_to`	A `Person` is assigned to an `Account` or `Activity`.
`reports_to`	A `Person` reports to another `Person` in the org chart.
`manages`	A `Person` manages another `Person`, an `Account`, or a team.
`owns`	A `Person` or `Organization` owns an `Account` or `Asset`.

Business

Edge	Meaning
`works_with`	Generic vendor, partner, or collaborator link between an `Organization` and another party.
`customer_of`	A `Person` or `Organization` is a customer of another `Organization`.

Activity

Edge	Meaning
`sent`	A `Person` sent an `Activity` (an email, a message, a transaction).
`received`	A `Person` received an `Activity`.
`created`	A `Person` created an `Asset`, `Account`, or `Activity`.
`modified`	A `Person` modified an `Asset` or `Account`.
`involves`	An `Activity` involves a `Person`, `Organization`, `Asset`, or `Account` without implying a sender or recipient role.
`co_recipient`	Two `Person` nodes appeared together on the same `Activity` or `Thread`.

Association

Edge	Meaning
`associated_with`	A meaningful but unspecified link between two entities. Used sparingly; prefer a more specific edge where possible.
`knows`	Two `Person` nodes have evidence of direct interaction.

Identity

Edge	Meaning
`has_identifier`	A `Person` or `Organization` has a stable `Identifier` (email, phone, handle, external ID).

Trust tiers

Every edge carries a confidence score. The platform applies qualitative trust tiers so that stronger claims require stronger evidence:

Employment edges (works_for, reports_to, manages) need the highest trust before auto-acceptance. Getting someone's employer wrong is expensive, so the bar is deliberately high.
Vendor and business edges (works_with, customer_of) require strong trust.
Associative edges (associated_with, knows) require moderate trust. These are the softer signals that hint at a relationship without asserting a role.
Activity edges (sent, received, involves) are typically derived from structured source data and clear that bar easily.

Specific numeric gates are not published here. They move as the platform learns from corrections, and publishing static numbers would invite adversarial calibration. Your agent sees the live tier configuration for your org via describe_schema.

Authority ordering

Every node and edge records who produced it. When two sources disagree, higher-authority sources win. Authority is ordered from lowest to highest as:

Deterministic rules (the extractor reading structured frontmatter).
AI inference (your agent writing back via write_to_graph).
User corrections (a human explicitly fixing a fact).
Admin overrides (org admins setting ground truth for their graph).

A user correction overrides an AI inference, even when the AI has high confidence. An admin override is final within an org. The full conflict resolution logic is not published; it is part of the schema contract returned by the API.

The canonical source

This page is the narrative reference. The live schema your agent actually uses is whatever describe_schema returns. Call it from any MCP client, or hit GET /schema on the Graph API with your org's API key.

curl

curl https://api.graphory.io/org/YOUR_ORG_ID/schema \
  -H "Authorization: Bearer gs_ak_your_api_key"

The response lists the node types, edge names, and trust tiers currently active for your org. Extraction rules are versioned; when the master ontology accumulates a new pattern, your schema reflects it automatically.

Graphory Labs

Ontology

Principles

Node types

Edge vocabulary

Structural

Employment

Business

Activity

Association

Identity

Trust tiers

Authority ordering

The canonical source