Content standards

Defines the rules curators must follow when naming entities, assigning types, filling properties, writing descriptions and structuring content on Geo. Applying these standards ensures data is accurate, consistent and queryable across the graph.

Entity Names

Entity names should be clear, consistent and follow standard conventions.

General rules

  • Use sentence case: capitalize only the first word and proper nouns (e.g., Developer tools, not Developer Tools).

  • Name length should match what the entity type requires for clarity. For most entity types, keep names concise ⇒ if a shorter name is unambiguous, use it. For entity types like Claims, where the name carries the full proposition, longer names are expected and correct.

    • Too long (for a project): Smart contract programming interface for developers → use Smart contract.

    • Correct length (for a claim): Blockwise sparse attention increases the efficiency of LLMs' attention mechanism.

  • Use singular forms for types (e.g., Person, not People; Company, not Companies).

  • Do not add parenthetical context to entity names (e.g., avoid Ethereum (blockchain)) ⇒ use the Type and Description fields instead.

  • Do not include abbreviations in entity names (e.g., avoid Federal Bureau of Investigation (FBI)) ⇒ abbreviations belong in a dedicated property field.

People

  • Use the full name only; no honorifics or titles (no Dr., Mr., President, Senator, Professor).

  • Titles and roles belong in the dedicated roles property, not the name field.

Projects & companies

  • Use the name the entity is publicly known by (e.g., Apple, not Apple Inc.).

  • Do not append legal suffixes to the entity name (e.g., avoid Apple Inc., OpenAI LLC, DeepMind Ltd).

  • Use the Legal name property to record the full legal name, including its structure.

Properties & relational property names

  • Keep property and relational property names concise and broadly applicable; a good property name can be reused across multiple types.

  • Avoid names so specific that they can only apply in one context.

    • Use this ⇒ Auditors (applies to any audit, exploit or security review).

    • Use this ⇒ Side effects (used across Drug, Vaccine, Supplement types in Health).

Types

When a fitting type exists, assign it. When it doesn't, leave the field blank. Forcing a poor fit is worse than no type at all; a mistyped entity inherits the wrong schema, surfaces incorrect properties and misleads anyone querying the graph.

If unsure, propose a type or seek help on Discord.

Assigning types

  • Assign a type before publishing only when a fitting one exists; do not force a type just to avoid leaving the field blank.

  • Assign as many types as are relevant, but only types that genuinely apply to the entity.

  • If an existing type fits, use it; avoid creating a new type when one already exists that serves the purpose.

Using existing types

  • When using a type with a predefined schema, fill in the properties you can verify; do not fill fields with guessed, approximate or placeholder values just to avoid leaving them blank.

  • An empty field is better than an inaccurate one; submit verified values you are confident in.

Creating new types

  • When creating a new type, ask yourself: could this type classify entities beyond the ones I am submitting right now? If the answer is no, the type is too narrow.

  • Avoid types so narrow they can only ever apply to a single entity.

    • Use this ⇒ Transmission route (applies to any infectious disease).

    • Use this ⇒ Symptom (classifies any symptom across any disease or condition).

    • Not this ⇒ COVID-19 symptom (locked to one disease, cannot classify anything else).

  • When defining the type's properties, include fields that any entity of this type would need, not just the ones relevant to your current submission.

    • Use this ⇒ When creating a Condition type, adding properties like Symptoms, Body systems and ICD-10 code makes it useful for anyone documenting any medical condition, not just the one you're currently submitting.

Type names

  • Type names follow the same naming conventions as entity names: sentence case, singular form and no parenthetical annotations.

  • Example: Use this ⇒ Research institution. Not this ⇒ Research Institutions or Academic research institution (university).

Checking existing types first

Before making any property decisions, verify what already exists in the graph:

  • Search for an existing type that fits the entity you are submitting.

  • Check the type's predefined schema and use the type's property names; do not use custom names when an equivalent property already exists.

  • If a type with a full schema exists for your entity, fill in its properties rather than creating parallel ones outside the schema.

For background on how types and properties work, refer to** **Creating types and properties on Geo.

Properties & Relations

Properties are how structured data is stored on an entity. They are the backbone of the knowledge graph; the difference between an entity that is merely named and one that is truly connected and queryable.

Two types of values

Properties can hold two kinds of values:

  • Plain values: text, numbers, dates, URLs (e.g., a founding date, a website link).

  • Relational values: a link to another entity in the graph (e.g., a person's employer linking to an existing entity).

Relational properties are strongly preferred wherever a linked entity exists. Submitting a relation as free text (e.g., typing "Anthropic" in a project field instead of linking to the Anthropic entity) breaks the graph connection. It is one of the most common and impactful submission errors.

Using relational properties

  • Always search the graph before entering a value; if the entity already exists, link to it.

  • Never duplicate an existing entity just to fill a relation field; reference the existing one.

  • If the related entity does not exist yet, create it first, then link to it.

Filling in properties

  • Only submit values you can verify; an empty field is better than an inaccurate one.

  • Use the correct data type for each property; entering a date as plain text or a number as a string breaks queryability.

  • Keep data formats consistent across all entities in a submission ⇒ see Value consistency within properties below.

Adding new properties

If a property you need does not exist in the type's schema, you may add it, but it must include a description covering:

  • What the property captures.

  • What values are expected?

  • What data type does it use?

For guidance on data types and how to create properties correctly, refer to Creating types and properties on Geo.

Without a description, reviewers cannot assess whether the values submitted are accurate or consistent.

Value consistency within properties

When filling in property values, apply a consistent format across all entities in the submission:

  • Date properties must use a standard format throughout (e.g., do not mix 2012, 2012.5 and January 2012 across the dataset).

  • Properties that accept multiple values must use a consistent separator throughout.

  • Properties that reference other entities must be linked relationally ⇒ not entered as free text in some rows.

  • Properties that express a unit (e.g., file size, count) must use a consistent unit and format across the dataset.

Relation entities

Some relationships carry more information than a simple link can hold. When a relationship itself has properties, like a start date, an end date or a title. Geo models use a relation entity: a dedicated entity that represents the relationship and stores that additional context as structured data.

Whenever possible, prefer relation entities over free text. Writing "CEO since 2021" in a text field loses structure and cannot be queried. Modeling it as a relation entity with a title, start date and linked person makes the data queryable, consistent and reusable across the graph.

When to use relation entities

Use a relation entity when a direct link between two entities is not enough to capture the full picture. Common cases include:

  • A person's role at a company, where the relationship has a title, start date and end date.

  • A speaker's appearance at an event, where the relationship has a session, date and topic.

Topics & classifiers

Topics and other classifiers organize entities within a space. They are what make entities discoverable. When submitting entities:

  • Search existing topics before creating a new one; spaces like AI have hundreds of topics already defined; chances are the one you need already exists.

  • Assign all topics that genuinely apply, not just the most obvious one ⇒ a dataset used for both Language modeling and Code generation should carry both.

  • Topics should reflect how an expert in that domain would naturally categorize the entity.

Deduplication (manual entry only)

Before creating any new entity, check whether it already exists in the graph:

  • Search existing entities first; if it exists, reference it rather than recreating it.

  • If the entity already exists, you can still contribute by enriching it; fill in missing properties or improve existing data.

  • If you find multiple instances of the same entity, use the most populated one as your reference.

Proposing new types for Geo (root)

The Geo root space is the shared foundation of the knowledge graph. Types created there are inherited across all spaces, which is why curators cannot create types there directly ⇒ any addition must be reviewed and approved by the team first.

If the entity you are submitting does not fit any existing type, submit a proposal in the #ontology channel on Discord.

A valid proposal must include:

  • The proposed type name and description.

  • A list of properties with their descriptions and data types.

  • Whether each relation property is open or assigned to a specific type.

Allow up to one week for the team to review and respond. Plan your submission timeline accordingly.

For background on how types and properties work, refer to Creating types and properties on Geo.

Descriptions

The description is a default property on every entity; one of the first fields a contributor should fill in after setting the entity name and type. It is also the first thing a reader sees when previewing an entity, so it should give enough context to understand what the entity is and why it matters; concisely and neutrally.

Writing the description

  • Keep it to one or two short sentences, targeting around 50 words.

  • Cover the essentials: what the entity is and why it is significant.

  • Use a neutral tone: avoid promotional, negative or opinionated language.

  • Do not start the description with the entity name, a restatement of it or an article (e.g., avoid "Anthropic is a company...", "A...", "An...", "The...").

  • Write in third person.

What to avoid

  • Vague or generic openers that could apply to any entity (e.g., "This is a company that...").

  • Superlatives and marketing language (e.g., "the leading", "the world's best").

  • Unnecessary repetition of information already captured in properties (e.g., restating the founding date if it has its own property field).

Block Content

Block content lives above the properties container on every entity page. It is the flexible, rich-media layer of an entity, where narrative context, structured views and supplementary information live. It is separate from properties, which hold structured data.

To add a block, enter edit mode and type / to open the block menu.

Supported block types

  • Text: free-form narrative content, fully supports Markdown for formatting, links, lists and headings.

  • Image: standalone images to support visual context

  • Video: embedded video content.

  • Code: formatted code snippets.

  • Data: dynamic views over knowledge graph data (see below).

Data blocks

The most powerful block type. Instead of manually curating content, they surface entities, relations and queries directly from the graph and stay up to date automatically as the graph evolves.

There are three types:

  • Collection blocks: a manually curated list of entities; you control the contents explicitly.

  • Relation blocks: automatically display all relations of a specific type pointing from the current entity; updates automatically as relations change.

  • Query blocks: live queries that return all entities matching defined criteria (e.g., all Person entities in a given space); fully dynamic.

For background on how tables can be filtered, refer to Creating filtered tables on Geo.

Tabs

Block content is organized under the Overview tab by default. Additional tabs can be added to break content into structured sections (e.g., Projects, News, Media).

Each tab is backed by a dedicated entity of type Page.

To add a tab:

  • Create a new entity and assign it the type Page

  • Name the Page entity to match the tab label you want displayed (e.g., News).

  • Add a Tabs relation on the parent entity pointing to the Page entity.

Each tab requires its own Page entity; do not reuse an existing Page entity across multiple tabs or multiple parent entities. Tabs are reorderable by dragging and dropping the Tabs relations.

When to use block content vs. properties

  • Use properties for structured, typed data that belongs in the graph (dates, links, relations).

  • Use block content for narrative context, rich media and dynamic views that enhance understanding but are not themselves graph data.

Images

Every entity page supports one or two image fields: a cover and/or an avatar. Both appear in the entity header and are part of how the entity is presented publicly; they should be treated as required fields, not optional decoration.

Avatar

  • Used for people and projects to represent the entity's identity

  • Source from X (formerly Twitter) where possible; if unavailable, use LinkedIn or the official company/institution website.

  • Must be square, minimum 400×400 pixels.

  • The subject or logo must be properly centered.

  • Use editing tools (Canva, Figma, Photoshop) to crop or adjust if needed.

Cover

  • Used as the banner image at the top of the entity page.

  • Ideal dimensions: 2364×640 px.

  • Can be designed at 1192×320 px and exported at 2× scale.

  • The subject or logo must be centered.

  • Use editing tools to adjust if needed.

  • If using third-party images, ensure you have the appropriate rights; use only public domain images or images with a valid license permitting reuse.

General rules

  • Provide an avatar for entity types that have an Avatar property in their schema; primarily people, projects and tools. Do not add avatar images to abstract entities such as claims and tags.

  • Do not use low-resolution, distorted or uncropped images.

  • Do not use images that include watermarks or branding from other platforms.

Quality standards

Every submission is evaluated against five metrics. Understanding these metrics helps contributors build better submissions and helps curators apply consistent, fair assessments.

Accuracy & Factuality

All data is objectively correct. This covers:

  • Claims, relations and data points that are verifiably true.

  • Leadership roles, founding dates and affiliations that are confirmed against reliable sources.

  • No misattributed relationships or outdated information presented as current.

Structure quality & Ontology

The right types and properties are used throughout. This covers:

  • Relational properties are used wherever a linked entity exists, not in free text form.

  • Entities are organized via topics and other classifiers.

  • Naming conventions, date formats and data types are consistent.

  • No leftover template columns, parenthetical annotations in name fields or type mismatches.

Relevance

The submission includes the most important and useful entities for the bounty's domain. An expert browsing the dataset finds nothing obviously missing and nothing obviously out of place.

Completeness

The volume and coverage of the submission match or exceed what the bounty description asked for. Submissions that meaningfully exceed the target, in quantity and quality, are recognized accordingly.

When in doubt, ask

If you are unsure about the right type, property, naming convention or anything else covered in this guide, ask before publishing. It is always easier to get it right the first time than to correct it after the fact.

Reach out to a senior editor on Discord for guidance in proper channels.


Comments (0)
Loading comments...