This page explains the shared vocabulary behind gloria.dev. When you ask your agent to register a project, map a feature, define a coding standard, check a dependency, install a skill, or track documentation work, these are the terms that keep the product’s layers straight.
The ownership spine
Organization is the top-level account. Skills libraries are scoped to an organization, and projects are registered under it. If a team manages more than one workspace, the organization keeps them separate.
Project is the unit you usually select first. It is the working context for dependency work, feature mapping, coding standards, document work, and health-check work in the web app and agent flows. A project owns its dependency inventory, feature map, coding standards, documents, health checks, and settings.
See Domain Model for the structural view, or Register a Project for the practical flow.
Features and coding standards
Feature is a project-owned product capability. A feature maps the files and symbols that implement it, so the feature map gives Gloria a readable bridge from product language to source code.
Coding standard is a project-owned statement of how code should look, behave, or stay aligned with intent. It groups the project’s rules, snippets, check runs, and drift ledger into one shared standard.
Rule is one requirement inside a coding standard. Each rule states one expectation the code should satisfy.
Snippet is a reusable code example attached to a coding standard’s library. A snippet gives the standard a concrete pattern or known-good shape that can be reused or checked against.
Check run is one recorded pass of a coding-standard check for a project. It ties the current code to the standard and records the findings from that pass.
Drift ledger is the project-owned record of drift over time. It collects check-run history and findings so Gloria can keep track of where code no longer matches the standard.
See Features and Coding Standards for the related pages.
Dependencies and health checks
Dependency is anything a project relies on to operate, such as an external SaaS service or an internal system. Each dependency has a kind described in plain language as external SaaS or internal system, and a category that keeps the service list consistent across projects. Canary uses dependencies as the core unit it documents, checks, and notifies on.
Health check is a check registered for a dependency. It is not a note or a hand-written status. It runs on a schedule and can be a simple HTTP probe or an authenticated, service-specific check when the dependency needs one. The result tells gloria.dev whether the dependency is reachable, degraded, or down.
Status and cost evaluation turns check results into the states people see. gloria.dev compares current behavior with expected behavior to decide whether something is down, showing an elevated error rate, or running at higher-than-normal cost. Those states are derived from results; they are never entered by hand.
See Health Checks and Overview.
Skills and marketplaces
Skill is a versioned, shareable set of coding-agent instructions. You reach for a skill when you want your agent to do repeatable work in the same way each time.
Marketplace is where skills come from. The Skill Library can include official gloria.dev skills, organization-authored skills, and external marketplaces. From there, a skill can be searched, published, installed, or adopted, and the UI can show whether it is already present for the organization.
This layer is organization-scoped. It sits beside project work rather than inside a single project’s dependency inventory.
See Skill Library and Using with Coding Agents.
Publications and conversations
Publication is the named documentation unit exposed in Doc Holiday tooling. It is where documentation work is organized and published.
Conversation is the work thread attached to that documentation work. It gathers comments, diffs, and turns as the request moves forward. A documentation request can start a new conversation or attach to an existing one.
This layer belongs to Doc Holiday, not the dependency-monitoring side of gloria.dev. It keeps documentation work separate from the operational state of a project.
How the pieces fit together
The model is simple:
- Organization sits at the top.
- Project sits under an organization.
- Features belong to a project.
- Coding standards belong to a project.
- Dependencies belong to a project.
- Health checks belong to a dependency.
- Status and cost evaluation come from the check results.
- Skills and marketplaces are scoped to the organization.
- Publications and conversations manage documentation work in Doc Holiday.
That separation is the point. One layer describes what a project relies on. Another layer describes the product capabilities it wants to keep implemented and the standards it wants the code to follow. Another layer describes the skills your agent can use. A third layer tracks documentation work. Together they give gloria.dev a shared vocabulary for comparing what was intended with what was built, and where drift has appeared.
Want to go deeper? Head to Overview or Domain Model.