Build an Intelligent CRUD Application on Holo Engine

The Idea: From CRUD to Intelligent CRUD

Most business software begins with CRUD: create, read, update, and delete records. A CRM stores customers and deals. An inventory system stores locations and stock. HR software stores people and events. Financial software stores transactions and period states.

The hard part comes later. The application accumulates thousands of useful states, but they are trapped in rows, tables, exports, and separate analytics pipelines. To detect an unusual warehouse pattern, predict a risky deal, find a missing approval, or search a policy document, teams typically copy the same operational data into another system and maintain another integration.

Holo Engine lets you build the application around a richer model:

The Engine is the application's persistent state layer. It stores records as nodes in a tenant-scoped tree, with paths, attributes, branches, and text documents. The same accumulated state can then be queried, filtered, audited for structural imbalance, searched semantically, used in a supervised learning loop, fed into a structural reasoning engine, analyzed for mathematical law discovery, or passed to a graph optimization solver.

The important design decision: intelligence is not a separate product bolted on later. It is a capability of the state that the product already creates.

The architecture, in one diagram

Your application API still owns authentication, permissions, validation, and user-facing business rules. Holo Engine owns the operational state for this workflow: records, tree branches, their attributes, imported rows, and indexed text.

The Data Model: Paths for Structure, Attributes for State

Every business record needs a stable home. In Holo Engine, that home is a path in a tree. Use paths for the part of the model that has a natural hierarchy, and attributes for the fields that describe a record.

For a CRM, a clean starting tree is:

/crm
  /customers
    /northstar-logistics
      /contacts
        /olga-petrova
      /deals
        /renewal-2026
  /segments
    /enterprise

The path tells us where the record belongs. Attributes tell us what the record currently is:

{
  "company": "Northstar Logistics",
  "segment": "enterprise",
  "stage": "proposal",
  "owner": "maya",
  "priority": "high",
  "country": "GE"
}

Use predictable, URL-safe labels such as northstar-logistics and renewal-2026. Keep the human-readable name in an attribute. This gives the UI stable paths even if a display name changes.

Step 0: Make One Authenticated Request Helper

All calls belong to one tenant, selected by the API key. In your server application, make a helper that adds the authorization header and passes JSON through unchanged.

const HOLO_BASE = "https://api.hiholo.ai";

export async function holo(path, method = "GET", body) {
  const response = await fetch(`${HOLO_BASE}${path}`, {
    method,
    headers: {
      Authorization: `Bearer ${process.env.HOLO_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: body ? JSON.stringify(body) : undefined
  });

  if (!response.ok) throw new Error(await response.text());
  return response.json();
}

This helper is not a second database. It is the safe boundary between a public UI and the Engine tenant key. Keep your API key in a server-side service or edge function; do not ship a tenant key to the browser.

Step 1: Create — Add a Branch and a Record

POST /api/insert adds a node under an explicit parent path. This is the right primitive when a user creates one object in a business application: a customer, a stock location, an employee, or a reporting period.

First create the CRM branches:

await holo("/api/insert", "POST", {
  parent_path: "/",
  label: "crm",
  attributes: { type: "application" }
});

await holo("/api/insert", "POST", {
  parent_path: "/crm",
  label: "customers",
  attributes: { type: "collection" }
});

Now create a customer. The same shape works for an individual record anywhere in the tree:

await holo("/api/insert", "POST", {
  parent_path: "/crm/customers",
  label: "northstar-logistics",
  attributes: {
    company: "Northstar Logistics",
    segment: "enterprise",
    owner: "maya",
    country: "GE",
    priority: "high",
    lifecycle: "active"
  }
});

For a hierarchical object, continue beneath the record. For example, create a contacts collection under the customer, then add individual contacts below it. The resulting path is already a useful identifier for links, audit screens, and navigation.

Create many records at once

Use POST /api/seed when onboarding a historical export or a large, flat dataset. It accepts an array of objects with string, number, and boolean columns; numeric values can be placed into quantile buckets. This is excellent for initial transaction history, historic opportunities, or a catalogue import.

await holo("/api/seed", "POST", {
  rows: [
    { segment: "enterprise", country: "GE", stage: "won", amount: 42000 },
    { segment: "mid-market", country: "GE", stage: "lost", amount: 8000 },
    { segment: "enterprise", country: "TR", stage: "won", amount: 97000 }
  ],
  target_key: "stage",
  numeric_bins: 4
});

Use explicit insert paths for the interactive product tree. Use seed for bulk historical rows and datasets that will later support pattern discovery or prediction. Both persist in the same tenant store and are available to downstream Engine capabilities.

Create searchable documents too

Business applications also have unstructured state: a customer brief, a warehouse incident report, a policy, or an interview note. POST /api/feed_text stores and indexes one document as text nodes, without requiring an embeddings service.

await holo("/api/feed_text", "POST", {
  doc_id: "northstar-renewal-notes",
  text: "The client asked for a 24-month contract and wants a local support contact.\n\nThe renewal decision is planned for September.",
  metadata: {
    customer: "northstar-logistics",
    area: "sales",
    owner: "maya"
  }
});

This lets a normal CRM record hold both structured state and the documents that explain it.

Step 2: Read — Open, Filter, Search

Reading in a tree-based application has three simple modes.

Open a node and its immediate children

GET /api/get?path=... is the navigation primitive. It returns the selected node and its children.

const customer = await holo(
  "/api/get?path=/crm/customers/northstar-logistics"
);

Use it for a customer page, an employee profile, a location page, or an expandable sidebar.

Filter by an attribute

GET /api/search?key=...&value=... searches nodes by an attribute. It is a straightforward faceted filter for application screens.

const highPriority = await holo(
  "/api/search?key=priority&value=high"
);

The response includes a count and the matching paths. Your application can then open each path or present the paths directly as a results list.

Search the documents attached to the work

POST /api/query_text retrieves relevant indexed chunks from feed_text. It combines text terms with metadata terms such as owner:maya. Its result field is k, not top_k.

const notes = await holo("/api/query_text", "POST", {
  query: "renewal local support owner:maya",
  k: 5
});

Now a sales rep can find the relevant renewal note without moving documentation into another search service.

Step 3: Update — Change State Without Moving the Record

A record path is stable; its attributes are allowed to change. That is exactly what business software does all day: a deal moves stage, a stock item changes quantity, an employee gets a new manager, or a payment changes status.

Use the Engine update endpoint against the existing record path, supplying the state fields that changed:

await holo("/api/update", "POST", {
  path: "/crm/customers/northstar-logistics",
  attributes: {
    stage: "proposal",
    owner: "david",
    priority: "high",
    last_activity_at: "2026-08-02"
  },
  merge: true
});

At the UI level, this is just the Save button on an edit form. At the data level, it is a change to a persistent Engine node rather than a copied row in a shadow system. merge: true preserves existing attributes; set it to false only when the form deliberately replaces the whole attribute set. A successful update reports the path and counts for updated attributes, text chunks, and metadata.

Step 4: Delete — Remove a Test Record or Retire a Branch

Deletion is branch-aware. POST /api/clear can clear the whole tenant store, or it can remove a selected subtree. In an application, the scoped form is the useful one.

await holo("/api/clear", "POST", {
  path: "/crm/customers/northstar-logistics",
  remove_root: true
});

// For a destructive workflow, confirm deletion with
// GET /api/get?path=/crm/customers/northstar-logistics
// and expect a 404.

Use it for a customer record that must be removed with all of its contacts and deals, an abandoned project workspace, or a bad import branch. remove_root: true makes the selected branch itself disappear; set it to false when you need to retain the branch node and only clear what is below it. After a destructive call, verify the target with GET /api/get?path=...: the real test is a 404 Not found, not only a counter in the clear response.

Treat a full tenant clear as an administrative operation. A tenant clear also resets the cognitive model — useful when you want a fresh start.

Step 5: Learn — Turn Confirmed Outcomes Into a Product Capability

CRUD tells us what the application currently knows. Learning begins when the application has a clear question and confirmed outcomes. This is where the state platform becomes an intelligence platform.

For the CRM, the question might be: given a deal's segment, size bucket, age bucket, activity level, and owner workload, is it likely to be won?

The key is to send categorical, business-readable features and the eventual answer. POST /api/cognitive/observe records labeled observations immediately.

// 1. Add labelled observations as real outcomes arrive
await holo("/api/cognitive/observe", "POST", {
  target_key: "outcome",
  rows: [
    {
      segment: "enterprise",
      amount_band: "high",
      activity: "recent",
      decision_stage: "proposal",
      outcome: "won"
    },
    {
      segment: "mid-market",
      amount_band: "medium",
      activity: "silent",
      decision_stage: "discovery",
      outcome: "lost"
    }
  ]
});

// 2. Ask about one new, unlabeled record
const prediction = await holo("/api/cognitive/predict", "POST", {
  input: {
    segment: "enterprise",
    amount_band: "high",
    activity: "recent",
    decision_stage: "proposal"
  }
});

// 3. When reality arrives, close the loop
await holo("/api/cognitive/feedback", "POST", {
  input: {
    segment: "enterprise",
    amount_band: "high",
    activity: "recent",
    decision_stage: "proposal"
  },
  actual: "won"
});

The result contains a predicted value, confidence, and method. Show it alongside the record — the application now has its own intelligence layer, built from nothing but the states it already stores.

For an offline train/test check, use POST /api/cognitive/learn with train_rows, test_rows, and max_rounds; it returns the executed rounds, final accuracy, convergence, and round history.

Five Applications, One Pattern

The API is the same. What changes is the tree structure, the attributes, and the intelligence question you choose to ask.

See a tree for each product

/crm
  /customers
    /northstar-logistics
      /contacts /olga-petrova
      /deals /renewal-2026
        /events /proposal-sent

/warehouse
  /sites /tbilisi-01
    /locations /a-03
      /items /sku-1029
        /movements /2026-08-02-001

/people
  /departments /product
    /employees /alex-ivanov
      /onboarding /equipment
      /reviews /2026-h1
  /candidates /samira-khan

/finance
  /entities /hiholo
    /periods /2026-08
      /invoices /inv-000184
      /payments /pay-000184
      /reviews /review-000184

/projects
  /atlas
    /milestones /beta
      /tasks /mobile-permissions
        /updates /2026-08-02
    /tasks /api-integration

Domain notes that matter

CRM. Keep current deal state on the deal node. Add a child node for every meaningful sales event: call completed, proposal sent, legal review started, outcome confirmed. Feed account notes and meeting summaries through feed_text. Observe only the fields that were available at the time of the decision — otherwise the model can accidentally learn from the future.

Warehouse. Each movement is a child with a direction, quantity band, source, and timestamp. A receipt or pick updates on_hand on the SKU and creates a movement node. Run GET /api/anomaly?path=/warehouse/sites/tbilisi-01 as a structural audit signal; the returned barycenter_shift indicates imbalance or drift — a reason to inspect, not proof of error. GET /api/missing?path=... can surface predicted structural gaps that a human or business rule must verify.

HR. Each employee has a node with role, level, location, and status. Onboarding steps, reviews, and equipment assignments are child nodes. The learning loop can identify incomplete onboarding states, predict review bands, or flag missing documentation — automatically, from the same records HR already maintains.

Finance. Import historical transactions with seed, then build a review-priority classifier from past cases where the final review result is known. The prediction ranks which transactions deserve review first — turning the audit queue from FIFO into a priority queue powered by the engine's own history.

Before Shipping: A Release Checklist

Before you ship the first workflow, make these choices explicit:

Common Questions

Beyond CRUD: The Full Engine

The workflow above uses about a dozen endpoints. Holo Engine has thirty. Once your application's state lives in the tree, the same platform opens up capabilities that would normally require separate products, separate teams, and separate infrastructure.

None of this requires copying data to another system. The same tenant, the same tree, the same API key.

Structural Reasoning — /api/reason

The reasoning engine discovers structural laws from observations and applies them to answer queries. It supports 36 law types — arithmetic, conservation, classification, temporal sequences, logic, grid completion, and more. Unlike an LLM, it produces exact symbolic answers with confidence and energy scores.

// Discover the law behind a sequence, then query it
await holo("/api/reason", "POST", {
  observations: "Seq t1 10 t2 20 t3 30 | observe | Y 40\nSeq t1 5 t2 10 t3 15 | observe | Y 20",
  query: "Seq t1 100 t2 200 t3 300",
  target_key: "Y"
});

For a finance application, this means the engine can discover the rule behind a series of transactions and predict the next one. For a warehouse, it can detect that a sequence of movements follows a pattern — or breaks one.

Law Discovery — /api/discover

Given a dataset and a target column, the engine discovers the mathematical law governing the data — via DFT (Discrete Fourier Transform) or Zhegalkin polynomials over finite fields. It returns the law type, the polynomial, complexity, and coverage.

await holo("/api/discover", "POST", {
  rows: [
    { x: "0", y: "0" },
    { x: "1", y: "1" },
    { x: "2", y: "1" },
    { x: "3", y: "0" }
  ],
  target_key: "y",
  domain: ["0", "1"]
});

This is not statistics. This is exact law extraction — the engine tells you the algebraic rule your data follows.

Graph Optimization — /api/graph_solve

A universal graph solver running on the adelic hyperbolic tree. Supports TSP, shortest path, assignment, capacitated VRP, flow networks, multi-depot routing, time windows, and job shop scheduling. Graph nodes are embedded onto the Poincaré disk — hyperbolic distance guides the search.

await holo("/api/graph_solve", "POST", {
  dsl: "TASK shortest_path\nNODE A B C D\nEDGE A B 1\nEDGE B C 2\nEDGE C D 1\nEDGE A D 5\nSOURCE A\nTARGET_NODE D"
});

For a warehouse application, this is route optimization across delivery sites. For a finance application, this is transaction flow optimization. For a project management tool, this is critical path scheduling. All from the same engine, all from the same state.

Multi-Agent Coordination — /api/v2/connectome/solve

Distributed constraint satisfaction for business coordination. Multiple agents — each with their own rows, constraints, and objectives — are solved together with exact rational arithmetic. The connectome decomposer splits large problems into blocks, solves independently, and coordinates through iterative rounds.

await holo("/api/v2/connectome/solve", "POST", {
  agents: [
    {
      id: "sales",
      rows: [{ x_budget: 10, x_headcount: 3 }],
      constraints: [
        { label: "budget_limit", op: "le", coefficients: { x_budget: 1 }, rhs: 50 }
      ]
    },
    {
      id: "engineering",
      rows: [{ x_budget: 20, x_headcount: 5 }],
      constraints: [
        { label: "headcount_limit", op: "le", coefficients: { x_headcount: 1, x_budget: 1 }, rhs: 100 }
      ]
    }
  ],
  bounds: [
    { variable: "x_budget", min: 0, max: 100 },
    { variable: "x_headcount", min: 0, max: 20 }
  ]
});

For an ERP, this is departmental budget allocation. For a project tool, this is resource assignment across teams. For a CRM, this is territory balancing across sales reps.

Anomaly Detection & Gap Analysis — /api/anomaly, /api/missing

The tree structure itself carries signal. /api/anomaly returns a barycenter shift for each node — a measure of structural imbalance or drift. /api/missing predicts which elements should exist in a category but don't, using twin-slot theory.

// Audit a warehouse branch for structural imbalance
const audit = await holo(
  "/api/anomaly?path=/warehouse/sites/tbilisi-01"
);

// Predict missing SKUs in a product category
const gaps = await holo(
  "/api/missing?path=/warehouse/sites/tbilisi-01/locations/a-03/items"
);

No analytics pipeline. No ETL job. No separate monitoring stack. The tree knows its own structure — and it knows when something is missing.

Nearest Neighbor on the Poincaré Disk — /api/nearest

Find the k nearest neighbors of any node in hyperbolic space. Distance is computed via native Z-coordinates — no embeddings, no vector database. Useful for recommendations, similarity search, and clustering.

// Find the 5 most similar customers to Northstar
const similar = await holo(
  "/api/nearest?path=/crm/customers&k=5&z_re=0.12&z_im=0.34"
);

Holo Language — /api/holo_exec

A Turing-complete language to orchestrate all Engine APIs in a single call. Natural-language syntax: set x = 5, if x > 5 then ... end, while i < n do ... end. Built-in functions include sqrt, json_parse, http_get, http_post, and more. No semicolons, no curly braces.

await holo("/api/holo_exec", "POST", {
  code: "set customers = invoke http_get with \"/api/get?path=/crm/customers\"\nset count = length of customers.children\nprint at count\nif count > 10 then\n  print \"Large portfolio\"\nelse\n  print \"Growing portfolio\"\nend"
});

One call. One language. The entire engine.

The Full Endpoint Map

Start with CRUD. Add intelligence when the data is there. Add reasoning, discovery, and optimization when the business needs it. The same engine, the same tree, the same tenant — no migrations, no ETL, no new infrastructure.

Proof, Not Promises: We Ran the Workshop on Real Data

We did not stop at writing this workshop — we ran it, step by step, on two real business datasets against the production engine: the Maven Analytics CRM Sales Opportunities pipeline with 8,800 opportunities, and the canonical IBM Telco Customer Churn dataset with 7,043 customers. Every endpoint on this page returned a real answer on real data — and you can download the same datasets and reproduce every number below. Here is what happened, and what it hands a business that builds this way.

Learn — a risk-ranked pipeline, from records you already store

We trained the cognitive loop on confirmed outcomes and scored records it had never seen. The engine learned the difference between a deal that closes and one that dies, and between a customer who stays and one who churns:

Accuracy is not the headline — the trajectory is. Churn accuracy climbed from 0.75 to 0.80 as the training history grew from 1,000 to 3,000 customers. The model gets smarter with every outcome the application records. For a business: the deal queue and the renewal list become a risk-ranked queue instead of FIFO. Reps and retention teams call the accounts most likely to churn or close first — a direct conversion and retention win, from state that already exists, with no ML pipeline, feature store, or embeddings service to build or feed.

Discover — the rules your data already follows

Given nothing but the raw numbers, /api/v2/discover/holo-formula recovered a law the business actually cares about: churn risk decays with customer tenure, fit as a logarithmic curve with R² = 0.968. Risk peaks in a customer's first two years and falls off after. For a business: front-load onboarding and retention spend in year one and two, and stop over-investing later. The same endpoint recovered the pipeline's pricing structure (deal value ≈ list price, R² = 0.996) — on live data, that doubles as a continuous data-integrity check that flags the moment billing drifts from pricing.

Reason, Solve, Optimize — decisions, not just dashboards

/api/reason answered a new customer's churn risk correctly with a full trace of which factors drove it (month-to-month contract, short tenure, no security add-on). /api/solve assigned four distinct retention offers to four high-risk customers with no double-booking. /api/graph_solve routed a field-retention team across five at-risk segments, and /api/v2/connectome/solve split a retention budget across contract tiers with the constraints verified exactly. For a business: auditable risk reasons instead of black-box scores, conflict-free offer assignment, fewer miles and more visits per field day, and a provably consistent budget split — all from the same tenant.

What this hands a business

Where to Go Next

CRUD systems normally stop at storage. An Intelligent CRUD application keeps the familiar controls — create a record, open it, edit it, delete it — but allows the same state to become searchable context, a structural signal, a prediction engine, and a growing intelligence layer.

That is the practical promise of building on Holo Engine: not a separate AI layer next to the application, but an application whose own state can learn, reason, discover, and optimize.

Start small. Build the customer page, the stock screen, the leave request, the invoice queue, or the Kanban board. Holo Engine gives that same application state a route into search, structural signals, predictions, reasoning, and optimization — without first exporting it to a separate intelligence stack.