What is Ontology?

Without Ontology configured, you cannot use Analytics or Agentic.

Integrations sit under Ontology: they clean, transform, and standardize data that is loaded into Ontology. Analytics and Agentic sit on top of Ontology and pull the data they need.

Entities follow the employee lifecycle (candidate → employee → events over time). Relating them lets you connect dots—for example, how long it took someone to go from candidate to employee, or how many applications a requisition received versus how many people were hired.

Everyone who has put in a bid for any position at the company—via application, recruiter outreach, or referral. Aragorn needs to know which data you treat as candidate data.

The actual applications a candidate submitted. One candidate can have many applications (for example, Software Engineer I, Software Engineer II, and Senior Engineer).

The possible statuses an application can move through (for example, submitted, in review, rejected, hired). Organizations often share common statuses and may add unique ones for their process. One application can pass through multiple statuses over time.

On a high level, the job that needs to be filled.

A candidate submits an application toward a requisition.

Common statuses include open, closed, or filled. Organizations may add others. Open means applicants can apply; filled or closed means hiring for that requisition has stopped (for example, roles filled, or hiring paused after a business event).

When an application is hired, the person moves from candidate to employee and receives an employee ID. The same person may still have a candidate record. Organizations often link candidate to employee via a candidate ID on the employee record, or via email.

Once someone is an employee, events record what happens while they work at the company. Events include a date, and usually a reason.

Anything that changes job title or role—hire into a role, promotion, demotion, or transfer. Every employee has at least one position event (the initial hire into a role).

Changes to employment status—for example, active → leave (medical, family, or other reason), or active → terminated (quit or other exit). Someone can move active → leave → active again → terminated over time.

Anything that changes pay or salary—for example, merit increase, equity award, or a promotion that also changes compensation. The same real-world change can produce both a position event and a compensation event.

You do not need to send Aragorn a monthly snapshot file. Aragorn generates an employment snapshot so you can answer “who / what / when” questions as of a past date.

Because events are effective-dated, Aragorn can replay history: given a date (for example, December 20, 2022), it uses events in effect as of that date—status, position, salary—to reconstruct what the organization looked like then.

Other analytics platforms often ask you to send a full data file every month. If HR later backdates a correction (for example, hire date was wrong), those platforms typically cannot accept a one-off fix; you may need to resend month files from the correction date through today because the change ripples forward.

With Aragorn, you update the event. Replay uses event dates, so history regenerates correctly without rebuilding every monthly file. That matches how HR actually works with backdated corrections.

Some entities are optional. You can start Analytics with the minimum required data (for example, employee-focused analytics only). Optional areas include talent-acquisition depth and pay detail.

Start, promotion, and exit events are subsets of status (or related) events. You tell Aragorn which statuses count as starting, promotion, or exiting.

That matters because organizations invent internal statuses (for example, a code that means transfer between sectors—terminated in one sector but still active in the company).

Aragorn cannot assume what those codes mean. Categorizing them unlocks richer analytics such as forecasting starts versus exits and attrition-style insight.

Optional. Salary on paper (for example, 100k) may not match money actually paid if someone had unpaid leave. If Aragorn can read pay statements, you can sum actual payments, compare expected (sum of salaries) vs actual spend, and support workforce planning and budgeting questions. You do not need to configure org chart in Ontology to start Analytics.

Every load into an Ontology entity is recorded as a job (date, updated record counts, errors with messages). You can track jobs per entity (for example, employees) for transparency and troubleshooting.

Analytics and Agentic operate on the data in Ontology. If a headcount looks wrong in Analytics:

Aragorn surfaces the dataset Analytics is built on so you do not need a separate data lake just to see what the numbers came from.

Most organizations use Integrations to feed Ontology. If you load files instead:

The uploaded file should look like the table view for that entity once loaded.