Home

@ontomorph/holon-types

The shared vocabulary of HOLON. Types, enums, error classes, and result helpers that describe the HOLON clinical-knowledge API. No HTTP client. No runtime dependencies.

The @ontomorph/holon-client SDK and the HOLON services both build on this package. The vocabulary identifiers, error codes, and entity shapes you import here are the exact ones the API speaks, so the client and the server never disagree about the contract.

Why you would want it

One definition of the contract, shared by client and server.

One set of error codes

Every HOLON error and error response uses the same ErrorCode enum, carried by HolonError. A caught error means the same thing wherever it surfaced.

One result convention

Services return ServiceResult<T>, built with ok() and err(). Callers branch on .success instead of wrapping each call in try/catch.

One set of entity shapes

Concept, ConceptResponse, and the rest mirror what the API returns. Client code and server code read the same fields.

When to install it directly

Most applications should install @ontomorph/holon-client. It re-exports the types it needs and adds the HTTP methods.

Reach for @ontomorph/holon-types on its own when you are:

Building your own transport

A custom client, or a server that speaks the HOLON contract.

Sharing codes across a codebase

You want HOLON enums and error codes in your code without pulling in the client.

Minimal example

// look up a concept, return a ServiceResult
import { ok, err, ErrorCode, type ServiceResult } from "@ontomorph/holon-types";

function lookup(id: number): ServiceResult<Concept> {
  const row = find(id);
  return row ? ok(row) : err("no such concept", ErrorCode.CONCEPT_NOT_FOUND);
}

Where to go next

• Getting-Started: install and the three things you get.
• Concepts: the glossary behind these types.
• Guides: task-by-task usage.
• Use-Cases: end-to-end scenarios.
• API-Reference: every exported symbol.
• FAQ: common questions.