DEV Community: HomelessCoder

Introducing the Omnismith MCP Server: Connect Claude Desktop & Cursor with One-Click OAuth

HomelessCoder — Wed, 02 Sep 2026 19:51:42 +0000

Connect your desktop AI assistants directly to Omnismith using our official Model Context Protocol (MCP) server. Discover schemas, query dynamic entities, and trigger automations with zero proxy configuration.

As AI assistants transition from simple chat windows into proactive operators, connecting them to live business data has become essential. The official Omnismith Model Context Protocol (MCP) Server is now live at https://mcp.omnismith.io/mcp.

Equipped with native OAuth 2.0 PKCE authentication and Streamable HTTP transport, developers and operators can connect desktop AI tools like Claude Desktop and Cursor directly to Omnismith — with zero custom proxy scripts or local daemons. Antigravity connects via a static API token in the Authorization header.

Why Connect Your AI Assistant to Omnismith via MCP?

Traditional AI tools often lack real-time context about your business objects, inventory, servers, and operational records. By connecting Claude or Cursor to Omnismith via the Model Context Protocol, your AI assistant gains structured, authorized access to your operational backend:

Instant Schema Awareness: AI assistants can autonomously explore active templates, attributes, list choices, and entity relations using the dynamic schema graph.
Natural Language Data Management: Create, update, filter, and inspect structured records across your project workspaces directly from the chat prompt.
Automated Schema Scaffolding: Describe your business domain in plain English (e.g., "Design an IoT fleet tracker with battery metrics and maintenance schedules"), and your assistant builds the complete template, attribute groups, and workspace views in a single pass.
Zero-Code Agent Observability: Desktop assistants can self-report tool execution traces and operational status directly into dedicated audit templates in Omnismith.

One-Click OAuth Connection

Connecting an MCP client used to require manual API key management or running brittle command-line bridges. With our new OAuth 2.0 PKCE implementation:

In Claude Desktop, navigate to Settings > Connectors > Add Custom Connector.
Enter the server URL: https://mcp.omnismith.io/mcp.
Approve access in the Omnismith authorization screen to select your project.
Your assistant is immediately armed with Omnismith schema discovery, entity querying, and data scaffolding tools.

Antigravity setup note: Connect Antigravity by adding the MCP server URL along with a static API token (e.g. omni_live_secret_key_...) in the Authorization header of its MCP server config.

Getting Started

The Omnismith MCP Server is available across every subscription plan, including Free — MCP access isn't gated by tier.

Check out our step-by-step guide on Zero-Code AI Agent Observability for practical dogfooding workflows.
Explore available data modeling patterns in the Headless Backend Guide.

Zero-Code AI Agent Observability: Auditing Claude Desktop & MCP Tool Calls with Omnismith

HomelessCoder — Tue, 01 Sep 2026 09:59:53 +0000

Desktop AI assistants execute powerful tools via MCP, but observing them often requires heavy proxy middleware. Learn how to achieve domain-agnostic, prompt-driven agent observability in Omnismith with zero custom code.
As AI assistants evolve from conversational chat interfaces into autonomous agents equipped with Model Context Protocol (MCP) toolkits, they are executing real-world operations: querying databases, updating cloud infrastructure, modifying files, and refactoring business schemas.

Yet in most developer and enterprise environments, these actions remain a black box—ephemeral tool-call logs trapped inside local client sessions without durable audit trails, relational attribution, or aggregated operational visibility.

In this article, we demonstrate how to achieve zero-code, prompt-driven AI agent observability by connecting Claude Desktop directly to Omnismith via MCP. We will examine the practical mechanics, the architectural design of a domain-agnostic agent execution schema, and real-world lessons learned from dogfooding autonomous assistant auditing.

The Desktop AI Observability Blindspot

When developers use desktop AI clients (such as Claude Desktop) equipped with MCP connectors, agents execute multi-step workflows across diverse tool servers.

While traditional backend microservices rely on OpenTelemetry collectors and APM agents, desktop AI clients lack native webhook configurations to ship internal tool telemetry. Traditional observability workarounds often require:

Writing custom proxy wrappers around every MCP server over stdio.
Managing separate log-forwarding daemons.
Maintaining brittle client-side middleware.

However, modern LLMs already have complete semantic awareness of their intent, the tools they invoke, and the resources they interact with. By giving the assistant access to a dynamic schema platform like Omnismith and providing a lightweight operating directive, the agent can autonomously self-report structured execution traces with zero external infrastructure.

Architectural Evolution: Designing an Honest, High-Signal Schema

When designing the ai_agent_execution schema in Omnismith, an initial intuition might be to request exact wall-clock metrics like latency_ms.

However, practical dogfooding with Claude Desktop revealed key architectural lessons:

1. Swapping `latency_ms` for Qualitative `Duration` Buckets

Without native OS timer bindings, asking an LLM to self-report latency_ms produces pseudo-precise estimates. A far more honest and reliable signal for prompt-driven auditing is a qualitative list attribute:

Fast: Instant lookups, brief schema queries, or single-value reads.
Moderate: Multi-record searches, template mutations, or complex multi-field writes.
Slow: Heavy batch processing, large codebase inspections, or long-running tasks.

(Note: In automated backend agent pipelines using SDK middleware, numeric latency_ms metrics can still stream directly into Omnismith time-series tables).

2. Domain-Agnostic Relational Grounding (`resource_type` + `resource_id`)

A truly actionable audit log must answer what was touched. By pairing a generic resource_type with resource_id, every trace is linked to the exact system artifact affected.

Because Omnismith schemas are dynamic and domain-agnostic, these fields adapt seamlessly to any business domain—whether tracking e-commerce operations (Order, Customer, Invoice), cloud infrastructure (Cluster, Deployment, Service), or developer tools. In our concrete dogfooding scenario below, resource_type classifies operations across Omnismith primitives (Template, Entity, Workspace, Attribute, Dashboard, Automation, Project).

3. Workflow Correlation with `session_id`

Multi-step user requests often trigger a sequence of 5–10 distinct tool calls. Introducing a session_id (or correlation ID) enables grouping individual executions into a coherent, end-to-end trace.

4. Categorization & Failure Diagnostics

task_category: Classifies operations into Read, Write, or Investigation for high-level operational filtering.
error_message: Captures diagnostic stack traces or failure reasons when execution_status: error.

The Omnismith `ai_agent_execution` Schema

Here is the finalized schema structure modeled in Omnismith:

Template: ai_agent_execution (AI Agent Execution)
├── Group: Execution Details
│   ├── agent_id (Dimension: String) — e.g. "claude-desktop"
│   ├── tool_called (Dimension: String) — e.g. "update_template"
│   ├── execution_status (Dimension: List) — "success" | "error"
│   ├── duration (Dimension: List) — "Fast" | "Moderate" | "Slow"
│   ├── task_category (Dimension: List) — "Read" | "Write" | "Investigation"
│   └── session_id (Dimension: String) — Correlation ID
└── Group: Context & Diagnostics
    ├── resource_type (Dimension: List) — Target domain category
    ├── resource_id (Dimension: String) — Target UUID or Slug
    ├── prompt_summary (Dimension: Markdown) — User intent summary
    └── error_message (Dimension: Markdown) — Diagnostic error details

Step-by-Step: Enabling Observability in Claude Desktop

Step 1: Connect the Omnismith Custom Connector

In Claude Desktop:

Navigate to Settings > Connectors.
In top right, click Add Custom Connector.
Paste the Omnismith MCP Server URL: https://mcp.omnismith.io/mcp.
Click connect and authorize your project in Omnismith.
Verify that Omnismith connector tools (create_entity, get_schema_overview, search_entities, etc.) are active.

Step 2: Ask Claude to Create the `ai_agent_execution` Schema

The schema above doesn't exist yet in a fresh project — nothing can log against it until Claude creates the template and its attributes. Point Claude at the schema and ask it to build it directly through the connector:

"In Omnismith, create a new template called ai_agent_execution with two attribute groups. Execution Details: agent_id (text), tool_called (text), execution_status (list: success, error), duration (list: Fast, Moderate, Slow), task_category (list: Read, Write, Investigation), session_id (text). Context & Diagnostics: resource_type (list), resource_id (text), prompt_summary (markdown), error_message (markdown)."

Claude creates the attributes and the template through the connector's schema tools (create_attribute/create_template, or the combined scaffold_data_model call) — no manual configuration in the Omnismith UI. Confirm the template exists with get_schema_overview before moving to the next step.

Step 3: Configure the Prompt Directive

Add the following instruction to your Claude Desktop Project instructions or system prompt:

"You are operating with Omnismith observability enabled. Whenever you perform a complex workflow or invoke custom tools, always record an execution trace in Omnismith by invoking the create_entity tool with template ai_agent_execution including agent_id: claude-desktop, tool_called: <tool_name>, execution_status: success|error, duration: Fast|Moderate|Slow, task_category: Read|Write|Investigation, resource_type: <type>, and resource_id: <id>."

For a setup that persists without bloating every system prompt, wrap this directive as a Claude Skill instead of a one-off paste: in Claude Desktop, go to Customize > Skills > Create skill — or just ask Claude "turn this into a skill" and let the built-in skill-creator scaffold it. Skills are picked up automatically whenever they're relevant, rather than sitting loaded in every conversation, and the same skill works across chat, Cowork, the Code tab, and the API. (Requires a Pro, Max, Team, or Enterprise plan with code execution enabled.)

Step 4: Execute & Observe

When Claude Desktop performs tasks (such as inspecting schemas, editing records, or running calculations), it seamlessly logs execution entries:

{
  "template_slug": "ai_agent_execution",
  "attribute_values": [
    { "attribute_slug": "agent_id", "value": "claude-desktop" },
    { "attribute_slug": "tool_called", "value": "update_template" },
    { "attribute_slug": "execution_status", "value": "success" },
    { "attribute_slug": "duration", "value": "Moderate" },
    { "attribute_slug": "task_category", "value": "Write" },
    { "attribute_slug": "resource_type", "value": "Template" },
    { "attribute_slug": "resource_id", "value": "01a053a8-326e-7320-864c-4ae8ca9c3271" },
    { "attribute_slug": "prompt_summary", "value": "Refactored schema attributes and swapped latency metric" }
  ]
}

Dogfooding in Action: The Self-Auditing Assistant

In our practical test of this workflow, Claude Desktop was asked to refactor an existing dynamic template.

After completing the update, Claude immediately dogfooded the new schema shape by logging its own execution under:

Task Category: Write
Resource Type: Template
Duration: Moderate
Execution Status: Success

The entire trace populated directly in Omnismith's Workspace Table View:

This demonstrates that AI assistants can be self-governing, structured, and fully auditable across any operational domain without writing a single line of backend middleware or proxy infrastructure.

Conclusion

As AI agents become core operators across software environments, governance and auditing cannot be an afterthought.

By combining the Model Context Protocol (MCP) with Omnismith's dynamic runtime schemas, developers gain an instant, zero-code observability layer that turns ephemeral agent actions into structured, actionable, and immutable records.

Get started by exploring the AI Agent Auditing Blueprint in Omnismith.

Omnismith Engineering Telegram Channel

HomelessCoder — Fri, 28 Aug 2026 19:54:12 +0000

We now have an official Telegram channel: https://t.me/omnismith

Omnismith is the entity database with built-in observability, in-data AI analytics, and flat pricing with unlimited team collaboration.

On Telegram, we’ll be sharing:

• Ready-to-use API recipes (cURL, Python telemetry scripts, webhook alerts)
• Step-by-step blueprints for IT ops, IoT fleet monitoring, and AI agent auditing
• Deep dives into zero-downtime schema evolution & query security
• Platform changelogs and roadmap updates

Follow along here: https://t.me/omnismith

How I Track Website Demo Requests with Omnismith (and Instant Telegram Alerts)

HomelessCoder — Tue, 11 Aug 2026 07:30:00 +0000

Learn how I configured our own Book a Demo workflow on omnismith.io using dynamic schemas, REST endpoints, and instant Telegram automations.

When launching a product or publishing a landing page, capturing prospective customer inquiries and notifying your team immediately is essential for quick follow-ups.

Teams often face a compromise: either pay for rigid, costly CRM subscriptions or spend valuable engineering hours creating backend database tables and custom email scripts.

When building the Book a Demo page for Omnismith, I chose a third option: using Omnismith itself to collect submissions, store structured records, and trigger real-time team alerts.

Here is how I set up our complete end-to-end lead tracking workflow in just a few minutes.

Workflow Overview

The setup connects a public website form to a team Telegram channel in three straightforward steps:

Visitor Submits Form: A prospective customer fills out the "Book a Demo" form on the website.
Omnismith Stores Lead: Omnismith receives the data and saves it directly into your organized leads table.
Team Gets Notified: An automation rule instantly formats and pushes the lead details to your team's Telegram chat.

1. Defining the Data Model

First, I defined the fields needed to store incoming lead details. Rather than writing database migrations or configuring fixed tables, I used Omnismith's built-in AI Assistant to scaffold the structure:

Hi! I want to start tracking demo requests from my website form. It collects Full Name, Work Email, Company Name, Phone Number, Primary Use Case, and "How can Omnismith help your team?" (named as "Message"). All attributes as string. Could you help me set that up?

Within seconds, the assistant created the Demo Request template populated with the six string attributes:

Because attributes in Omnismith are dynamic, new fields can be added or updated later without schema lock-in or downtime.

2. Ingesting Form Submissions via REST API

Our public Book a Demo page presents a clean, responsive contact form:

When a visitor submits the form, an extremely simple serverless function (like a Cloudflare Worker or API route) receives the form data and sends an HTTP POST request directly to the Omnismith /v1/entities endpoint, mapping form fields to attribute slugs:

POST /v1/entities
Content-Type: application/json

{
  "template_slug": "demo_request",
  "attribute_values": [
    { "attribute_slug": "full_name", "value": "Jane Doe" },
    { "attribute_slug": "work_email", "value": "jane@company.com" },
    { "attribute_slug": "company_name", "value": "Acme Corp" },
    { "attribute_slug": "phone_number", "value": "+15550000000" },
    { "attribute_slug": "primary_use_case", "value": "Dynamic EAV Backend" },
    { "attribute_slug": "message", "value": "We would like to test integrating our website forms with Omnismith." }
  ]
}

Upon receipt, Omnismith assigns a unique record identifier, validates attribute values, and writes the entry into storage.

3. Centralized Lead Records Dashboard

All submitted demo requests immediately populate the Omnismith dashboard under the Demo Request records view:

From here, team members can search, filter, and inspect incoming inquiries in real time without accessing raw database tools or navigating complex CRM menus.

4. Configuring Real-Time Telegram Alerts

Prompt response times make a huge difference in lead conversion. To ensure our team is notified instantly, I configured an automated Telegram alert in three simple steps:

Step A: Register the Telegram Notification Channel

In the Omnismith console under Automations > Notification Channels, I added a new channel using our Telegram Bot token:

Step B: Create the Automation Rule

Next, I defined an automation rule triggered whenever a new entity is created under the demo_request template:

Step C: Format the Alert Message

I structured the alert payload template using variable placeholders to map record fields directly into the Telegram message:

The Outcome: Instant Notifications for Every Lead

Whenever a visitor submits the demo form, our team receives a clear, formatted notification in our internal Telegram channel within seconds:

Key Implementation Considerations

Authentication & Proxying: To prevent exposing API access tokens on public frontend clients, requests can be routed through a lightweight serverless handler or backend proxy.
Input Validation: Basic form validation (such as email formatting and required fields) should be enforced on the client side before submitting the payload to the API.

Summary

By leveraging Omnismith's dynamic schema engine and event-driven automations, I built a reliable lead capture and notification pipeline in minutes—eliminating the need for custom database migrations or dedicated CRM software subscriptions.

Extending Slugs Across Templates and Entities for Deterministic API Workflows

HomelessCoder — Sat, 08 Aug 2026 17:27:03 +0000

Eliminate identifier resolution queries in automated ingestion pipelines. Omnismith extends project-unique slugs across templates and entities for deterministic API workflows.

The Problem with UUID-Only Ingestion

Automating entity management and metric ingestion requires continuous interaction with platform schemas. Prior to platform-wide slug support, writing data to Omnismith required external scripts to maintain or fetch UUIDv7 identifiers for attributes and templates.

Ingestion scripts and ETL jobs either hardcoded generated UUIDs across environments or executed pre-flight HTTP requests (GET /v1/templates, GET /v1/attributes) to resolve human-readable schema definitions into target UUIDs. This pattern added network latency, introduced points of failure during schema deployment across projects, and increased code complexity in stateless pipelines. Additionally, schema-aware AI Assistant workflows executing via Model Context Protocol (MCP) required extra context lookups to map user intents to internal platform identifiers before writing records.

Architecture of Universal Slug References

The extension of project-scoped slugs across attributes, templates, and entity write endpoints provides a deterministic mechanism for defining and populating structured records without initial lookup queries.

Attributes declare a project-unique string identifier during creation. Templates adopt a corresponding slug property and reference required attributes by attribute_slug during definition. When instantiating or updating entities, endpoints accept template_slug and attribute_slug parameters.

The ingestion pipeline resolves incoming slugs to underlying UUIDv7 primary keys during payload validation. Entity read endpoints support the ?attribute_key=slug query parameter to return attribute dictionary maps keyed by string slugs. The in-app AI Assistant leverages this interface through MCP tools, generating payload structures directly from schema definitions without intermediate identity resolution calls.

End-to-End API Sequence

The following sequence illustrates creating an infrastructure metric attribute, binding it to a compute template, instantiating an entity record, and reading the entity state using slugs.

Define a metric attribute with a slug identifier:

curl -X POST "https://api.omnismith.io/v1/attributes" \
  -H "Authorization: Bearer $OMNI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CPU Utilization",
    "attribute_type": 1,
    "data_type": 1,
    "description": "Host CPU load percentage",
    "slug": "cpu_usage"
  }'

Response:

{"id":"019fe205-c125-735b-98bd-86851e8baf15"}

Bind the attribute to a template using slug and attribute_slug:

curl -X POST "https://api.omnismith.io/v1/templates" \
  -H "Authorization: Bearer $OMNI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Compute Node",
    "slug": "node",
    "category": "Infrastructure",
    "attributes": [
      {
        "attribute_slug": "cpu_usage",
        "default_value": null
      }
    ]
  }'

Response:

{"id":"019fe206-e9d6-7349-b628-f9e9474622a2"}

Instantiate an entity using template_slug and attribute_slug:

curl -X POST "https://api.omnismith.io/v1/entities" \
  -H "Authorization: Bearer $OMNI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "template_slug": "node",
    "attribute_values": [
      {
        "attribute_slug": "cpu_usage",
        "value": "84.2"
      }
    ]
  }'

Response:

{"id":"019fe207-38eb-7182-9a5f-70cdaeea34f2"}

Retrieve the entity with slug-keyed attribute values:

curl -X GET "https://api.omnismith.io/v1/entities/019fe207-38eb-7182-9a5f-70cdaeea34f2?attribute_key=slug" \
  -H "Authorization: Bearer $OMNI_TOKEN" \
  -H "Content-Type: application/json"

Response:

{
  "id": "019fe207-38eb-7182-9a5f-70cdaeea34f2",
  "template_id": "019fe206-e9d6-7349-b628-f9e9474622a2",
  "template_slug": "node",
  "created_at": "2026-08-08T15:39:11+00:00",
  "updated_at": "2026-08-08T15:39:11+00:00",
  "attribute_values": {
    "cpu_usage": {
      "value": "84.2",
      "custom_value": "84.2",
      "reference_entity_id": null,
      "attribute_id": "019fe205-c125-735b-98bd-86851e8baf15",
      "attribute_slug": "cpu_usage"
    }
  }
}

Technical Tradeoffs

Using string slugs introduces operational considerations regarding schema immutability and lookup runtime:

Scope Uniqueness Constraints: Slugs are enforced as unique within the scope of a single project. Modifying an existing slug breaks downstream pipelines configured to send payloads with that string identifier.
In-Memory Resolution Overhead: API requests containing slugs undergo an in-memory resolution step to map strings to backend PostgreSQL UUIDv7 primary keys prior to executing entity updates or time-series storage writes in TimescaleDB.
Key Invariance: Underlying database entities retain fixed UUIDv7 primary keys. Internal foreign keys, append-only history logs, and time-series metrics maintain storage on UUID keys.

System Impact

Universal slug support across resources removes external state dependencies from automated pipelines. Scripts deploy and populate project schemas deterministically across environments using static configuration files. Integration layers and the schema-aware AI Assistant interact directly with readable keys while preserving relational storage speed and audit history tracking.

Configuring Event-Driven Automations and Telegram Notifications

HomelessCoder — Sat, 01 Aug 2026 11:17:14 +0000

Continuous telemetry streams require automated evaluation. Omnismith allows operators to attach trigger conditions to metric changes and dispatch immediate alerts via Telegram channels

High-frequency sensor streams and dynamic entity records provide real-time visibility into physical operations. However, monitoring dashboards continuously for operational anomalies introduces visual fatigue and delayed response times. When cargo temperatures in cold-chain fleet vehicles drift above safety thresholds, the platform must evaluate incoming metrics and notify operators automatically.

Omnismith provides an integrated automation subsystem that evaluates state changes directly against incoming attribute updates. By defining trigger events, boolean conditions, and notification actions through the API or administrative dashboard interface, technical teams can attach automated workflows to dynamic entity schemas.

Configuring Notification Channels

Before an automation can dispatch external alerts, a target notification channel must be registered in the project context. The notification channel layer isolates third-party credential management from individual workflow definitions.

Omnismith supports Telegram, custom HTTP webhooks, and device push notifications. To configure a Telegram bot channel, an operator submits a creation payload containing the bot token credential to the /v1/automation/notification-channels endpoint:

POST /v1/automation/notification-channels HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "type": "telegram",
  "name": "Fleet Dispatch Alerts",
  "credentials": {
    "bot_token": "1234567890:AAF1a2B3c4D5e6F7g8H9i0J1k2L3m4N5o6P"
  }
}

The server returns a channel record containing an immutable UUID identifier (019fb9ad-c8ae-7026-bc2d-6cffe1d73e27).

Alternatively, operators can register and review notification channels directly via the Omnismith dashboard interface:

Verifying Channel Connectivity

To ensure credentials and third-party routing are functional prior to linking active workflows, the API exposes a test endpoint:

POST /v1/automation/notification-channels/019fb9ad-c8ae-7026-bc2d-6cffe1d73e27/test HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "chat_id": "1234567890",
  "message": "Hello from omnismith.io!"
}

A status response of 200 OK verifies that the channel can transmit messages to the designated chat ID.

The platform UI provides a corresponding testing dialog to validate connectivity before deploying production automations:

Upon test dispatch, the bot delivers the verification payload directly to the specified Telegram chat:

Defining Event-Driven Automations

Automations operate on a declarative model comprising three structural components:

Triggers: State changes that initiate evaluation. Supported trigger types include on_entity_created, on_entity_updated, and on_attribute_changed.
Conditions: Boolean logic rules evaluated against entity attribute values. Operators include eq, neq, gt, lt, like, not-like, empty, and not-empty.
Actions: Targeted dispatches executed when all conditions evaluate to true.

Managing Execution Frequency with Cooldowns

High-frequency metric ingestion can stream telemetry updates multiple times per minute. If a refrigeration unit fails and continuously transmits values above the permitted threshold, evaluating the trigger on every incoming packet without restraint would flood external channels with duplicate alerts.

Automations incorporate a cooldownSeconds field. When set, the system throttles downstream action execution for the specified duration following a successful trigger event, preventing duplicate notifications while retaining continuous state evaluation.

Deploying a Temperature Excursion Automation

In the cold-chain fleet management model established in this series, the Vehicle template contains a Temperature metric attribute (019f51bf-3604-710b-9356-28f724f05f24). Standard operations mandate that cold-storage compartments remain at or below -15.0°C.

To configure an automatic Telegram alert for temperature excursions exceeding -15.0°C, the creation payload maps the vehicle template ID, attribute ID, threshold operator, and notification channel config:

POST /v1/automation/automations HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Cold-Chain Temperature Excursion Alert",
  "description": "Dispatches Telegram alerts when cargo temperature exceeds -15°C",
  "trigger": {
    "type": "on_attribute_changed",
    "templateId": "019f51bf-366c-72b9-94e1-0435af01e34a",
    "attributeId": "019f51bf-3604-710b-9356-28f724f05f24"
  },
  "conditions": [
    {
      "attributeId": "019f51bf-3604-710b-9356-28f724f05f24",
      "operator": "gt",
      "value": "-15",
      "mode": "current"
    }
  ],
  "actions": [
    {
      "type": "telegram",
      "config": {
        "channel_id": "019fb9ad-c8ae-7026-bc2d-6cffe1d73e27",
        "chat_id": "1234567890",
        "message_template": "EXCURSION DETECTED: Vehicle temperature has reached threshold limit.\nVehicle ID: {values.019f51bf-349a-7165-ad49-2312c3b6b073}\nMake/Model: {values.019f51bf-3534-71d9-b261-1f77fefcfdb1}\nTemperature: {previous.019f51bf-3604-710b-9356-28f724f05f24} → {values.019f51bf-3604-710b-9356-28f724f05f24}\nTime: {timestamp}"
      }
    }
  ],
  "cooldownSeconds": 300
}

Upon creation, the automation status defaults to active ("isEnabled": true).

Dynamic Message Template Interpolation

The message_template configuration leverages dynamic token syntax to build contextual alert payloads:

{values.<attribute_id>} interpolates the current value of any structural dimension or telemetry metric on the triggered entity.
{previous.<attribute_id>} resolves the preceding value prior to the update, displaying the exact directional delta (e.g., -18.5°C → -14.2°C).
{timestamp} injects the ISO-8601 execution timestamp.

When an attribute update triggers the evaluation engine, these tokens are resolved synchronously against the entity record before dispatching the payload to Telegram.

In the Omnismith administration interface, operators configure triggers and evaluation conditions step-by-step:

Following trigger definition, the UI guides operators through action selection, target notification channel binding, dynamic template placeholders, and cooldown settings:

Execution Audit and Log Evaluation

Every trigger evaluation that satisfies condition rules generates an execution record. Operators can audit execution history and troubleshoot notification delivery via the API:

GET /v1/automation/automations/019fb9d5-0679-7282-8622-50931e79dcb3/executions?limit=10 HTTP/1.1
Host: api.omnismith.io
Authorization: Bearer <token>

The response returns historical execution statuses, timestamp details, and specific action results:

{
  "data": [
    {
      "id": "019fb9e5-0bd2-7172-ab5a-45c6a4e34933",
      "automation_id": "019fb9d5-0679-7282-8622-50931e79dcb3",
      "entity_id": "019f51ca-8401-7243-910f-a22e901fb39f",
      "triggered_at": "2026-07-31T20:37:03+00:00",
      "completed_at": "2026-07-31T20:37:03+00:00",
      "status": "success",
      "action_results": [
        {
          "action_index": 0,
          "success": true,
          "error_message": null,
          "executed_at": "2026-07-31T20:37:03+00:00"
        }
      ],
      "error_message": null
    }
  ],
  "total": 1
}

Operators can also inspect execution logs, trigger statuses, and individual run details directly within the Omnismith management interface:

When an incoming sensor reading crosses the threshold line, the automation triggers and dispatches the formatted message to the target Telegram chat in real time:

If a third-party API error occurs (such as an invalid chat ID or network timeout), the execution record sets the status field to failed or partial_failure and populates the error_message attribute for diagnostic evaluation.

Architectural Performance Tradeoffs

Attaching automations directly to entity attribute changes minimizes the latency between metric ingestion and alert dispatch. However, configuring tight conditions on fluctuating metric attributes requires deliberate threshold design.

Defining narrow operational boundaries without applying appropriate cooldown durations can exhaust tier notification limits or trigger unnecessary alerts due to momentary sensor noise. Setting explicit numerical boundaries alongside calibrated cooldown intervals balances rapid anomaly detection against notification stream hygiene.

In the next entry of this series, we will expand beyond external notifications to construct complex business processes. By leveraging Webhook channels to execute requests directly back into the Omnismith API itself, we will demonstrate how state triggers can automate multi-step operational workflows and internal entity state transitions.

Ingesting Real-Time Telemetry and Configuring Observability Dashboards

HomelessCoder — Tue, 21 Jul 2026 21:03:23 +0000

Operational platforms must unify dynamic entity metadata with high-frequency sensor streams. Omnismith routes telemetry metrics directly to time-series tables for live visualization.

Operational visibility requires the tight unification of structured business context with high-frequency telemetry. In the cold-chain fleet management model established in previous entries, the system contains core records: 5 drivers, 7 vehicles, and 4 shipments. While the structural identity of a vehicle or the assignment of a driver remains stable, environmental attributes like Temperature and Fuel Level generate rapid, continuous data streams from physical hardware sensors.

Processing high-frequency streams through traditional document update paths creates structural friction. Relational index writes, entity validation logic, and document serialization overhead introduce latency, degrading the performance of real-time operational interfaces.

Omnismith isolates these data paths at the database layer. By decoupling structural metadata from high-volume telemetry, the platform maintains active indexing while capturing real-time streams for visual consumption on user dashboards.

Isolated Ingestion Pipelines

The architecture splits attribute types into dimensions and metrics. Dimensions represent the structural parameters of an entity (such as a vehicle's make/model or a driver's license status) and are updated via the document modification path. Metrics represent time-series values and flow through an independent path optimized for rapid writes.

Telemetry observations bypass the core entity document engine. When a refrigeration sensor or cellular gateway transmits hardware data, it communicates directly with the dedicated metric ingestion endpoint.

The Ingestion Payload

The ingestion endpoint accepts one or multiple metric observations for a specific entity ID. Data points are written straight to TimescaleDB tables, bypassing document-level indexing overhead.

POST /v1/entities/019f51ca-8401-7243-910f-a22e901fb39f/metrics HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "metric_values": [
    {
      "attribute_id": "019f51bf-3604-710b-9356-28f724f05f24",
      "value": "-18.5",
      "updated_at": "2026-07-20T12:00:00Z"
    },
    {
      "attribute_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
      "value": "85.2",
      "updated_at": "2026-07-20T12:00:00Z"
    }
  ]
}

Omitting the updated_at parameter defaults the observation timestamp to the server arrival time. The engine accepts the array with an HTTP status code 202 Accepted, shifting the values directly into the asynchronous stream processing layer.

Real-Time Telemetry Automation in Action

To demonstrate this high-frequency ingestion pipeline under realistic operating conditions, we can deploy an automated telemetry generator script. In a production setting, this script mirrors the behavior of cellular gateways mounted inside fleet vehicles or IoT sensor daemons.

The script targets multiple vehicle entities simultaneously, generating continuous metric updates for Temperature (e.g. -18.5°C refrigerated cargo baseline) and Fuel Level every 5 seconds:

import time
import random
import requests
from datetime import datetime

API_BASE_URL = "https://api.omnismith.io/v1"
API_TOKEN = "your-bearer-token-here"
UPDATE_INTERVAL_SECONDS = 5

VEHICLES = [
    {
        "name": "TRK-001 (Volvo FH16)",
        "entity_id": "019f51ca-8401-7243-910f-a22e901fb39f",
        "temp_attr_id": "019f51bf-3604-710b-9356-28f724f05f24",
        "fuel_attr_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
        "temp": -18.5,
        "fuel": 85.2,
    },
    {
        "name": "TRK-002 (Scania R-Series)",
        "entity_id": "019f51ca-84a7-714a-b9df-0712b47dc025",
        "temp_attr_id": "019f51bf-3604-710b-9356-28f724f05f24",
        "fuel_attr_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
        "temp": 5.0,
        "fuel": 42.0,
    }
]

def push_metrics(vehicle):
    # Simulate slight temperature fluctuation and fuel consumption
    vehicle["temp"] = round(vehicle["temp"] + random.uniform(-0.3, 0.3), 2)
    vehicle["fuel"] = round(vehicle["fuel"] - random.uniform(0.01, 0.05), 2)

    url = f"{API_BASE_URL}/entities/{vehicle['entity_id']}/metrics"
    payload = {
        "metric_values": [
            {"attribute_id": vehicle["temp_attr_id"], "value": str(vehicle["temp"])},
            {"attribute_id": vehicle["fuel_attr_id"], "value": str(vehicle["fuel"])}
        ]
    }
    headers = {"Authorization": f"Bearer {API_TOKEN}"}
    res = requests.post(url, json=payload, headers=headers)
    print(f"[{datetime.now().strftime('%H:%M:%S')}] {res.status_code} Accepted | {vehicle['name']} -> Temp: {vehicle['temp']}°C, Fuel: {vehicle['fuel']}%")

while True:
    for vehicle in VEHICLES:
        push_metrics(vehicle)
    time.sleep(UPDATE_INTERVAL_SECONDS)

As the automation pushes observations into the pipeline every 5 seconds, Omnismith Engine captures the high-frequency stream. The connected dashboard widgets update their visual series data dynamically without manual page refreshes:

Building the Observability Layer

For non-technical operators and fleet managers, raw database payloads must be compiled into visual shapes. Omnismith provides a dashboard manager that allows users to place, organize, and tie UI components directly to underlying templates and telemetry attributes.

Dashboards are constructed using a multi-block grid architecture. Four foundational block types handle distinct visual requirements:

Block Type	Primary Operational Purpose	Core Data Source
Stat	High-level KPI tracking and inventory totals	Aggregated template entity counts
Gauge	Immediate boundary check for vital telemetry metrics	Target entity metric value with min/max thresholds
Chart	Historical trend plotting and correlation analysis	Time-bucketed metric series across one or more entities
List	Contextual record views and reference correlation	Filtered entity document data with dimension parameters

Configuring Dashboard Blocks Programmatically

Behind the user interface, every visualization block is registered via the backend schema as a discrete entity container. The block configuration parameters outline the data-fetching requirements that the platform evaluates during frontend rendering.

1. Monitoring Fleet Status with Stat Blocks

To display the total scale of operations to a fleet manager, a stat block counts active items within a target template context. The block queries the entity directory to yield a singular integer.

POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "type": "stat",
  "title": "Total Active Vehicles",
  "config": {
    "template_id": "019f51bf-366c-72b9-94e1-0435af01e34a"
  }
}

2. Safeguarding Temperature with Gauge Blocks

A fleet operator must spot when cargo compartment conditions deviate from standard tolerances. A gauge block targets the target template and metric attribute ID of a specific fleet asset, evaluating the value against predefined operational bounds.

POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "type": "gauge",
  "title": "Vehicle 01 Refrigeration Unit",
  "config": {
    "template_id": "019f51bf-366c-72b9-94e1-0435af01e34a",
    "metric_attribute_id": "019f51bf-3604-710b-9356-28f724f05f24",
    "min": -30,
    "max": 10,
    "aggregate": "avg",
    "filters": [
      {
        "field": "id",
        "operator": "equals",
        "value": "019f51ca-8401-7243-910f-a22e901fb39f"
      }
    ]
  }
}

3. Analyzing Fuel Trends with Chart Blocks

To spot asset inefficiencies or unexpected telemetry drops over long journeys, engineers require multi-hour line charts. The chart block instructs the database engine to run mathematical time-bucketing on the underlying logs across entities belonging to the target template.

POST /v1/dashboards/019f52c1-881a-7b3c-9000-8f0000010000/blocks HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "type": "chart",
  "title": "Fuel Consumption Over Time",
  "config": {
    "template_id": "019f51bf-366c-72b9-94e1-0435af01e34a",
    "metric_attribute_id": "019f51bf-35aa-7340-86f7-5c903a6a38f0",
    "aggregate": "avg",
    "bucket_width": "15 minutes",
    "time_window": 86400,
    "entity_limit": 10
  }
}

The resulting single-asset view (TRK-001 Volvo FH16 Dashboard) combines Gauge blocks for real-time operational boundaries alongside 1-hour aggregated trend charts:

Runtime Computation Layer

When a user opens a dashboard, the application executes a batch resolution step across the active blocks via /v1/dashboards/{dashboardId}/blocks/{blockId}/resolve. The platform handles database query assembly internally.

For chart blocks, the system converts configuration inputs into optimized database aggregations. If a chart specifies a bucket_width of 15 minutes and an aggregate of avg, Omnismith uses native hypertable functions to roll up raw sensor inputs into a lightweight JSON array structure:

{
  "block_id": "019f52c2-11fa-7cbb-a330-1b2c3d4e5f6a",
  "title": "Fuel Consumption Over Time",
  "type": "chart",
  "bucket_width": "15 minutes",
  "series": [
    {
      "entity_id": "019f51ca-8401-7243-910f-a22e901fb39f",
      "entity_name": "TRK-001 (Volvo FH16)",
      "data_points": [
        { "time": "2026-07-20T12:00:00Z", "value": 85.2 },
        { "time": "2026-07-20T12:15:00Z", "value": 84.8 },
        { "time": "2026-07-20T12:30:00Z", "value": 84.1 }
      ]
    }
  ]
}

Non-technical managers interact exclusively with the resulting visual components: the text counters update, gauges swing to represent raw sensor readings, and line charts draw ongoing trends.

When expanded across the entire asset fleet, the Vehicles Monitoring dashboard aggregates time-bucketed metric series across multiple vehicle entities simultaneously, rendering a unified comparative stream:

Architectural Performance Tradeoffs

Bypassing standard document serialization for metric fields yields high transaction performance, but introduces distinct processing parameters.

Because the metric stream bypasses the primary EAV document engine, updates to high-frequency attributes do not re-index the parent entity record instantly. Filtering fleet entities via the global structural search engine (POST /v1/entities/search/{template_id}) operates on the entity document data state. If an operator requires real-time telemetry updates to trigger automations or update document filters, the platform utilizes an event-driven background pipeline to synchronize the entity document index asynchronously.

Unifying this real-time telemetry model with immediate visual components establishes a responsive environment for all platform participants. Engineers leverage high-performance endpoints to offload heavy device metrics, while non-technical project owners monitor visual dashboards containing unified business tracking data.

In the next entry of this series, the platform will utilize these incoming metric points to demonstrate event-driven automations, establishing trigger conditions that alert operators over external communication lines the instant anomalies are recorded.

Implementing Row-Level Access Control

HomelessCoder — Tue, 21 Jul 2026 20:07:15 +0000

Part 3 of the Omnismith "Core Platform Capabilities" series

Securing data inside shared multi-tenant environments requires robust authorization boundaries. Omnismith compiles dynamic row-level Access Scopes directly to database-level queries.

For platforms managing flexible database schemas, access control must extend beyond simple endpoint or structural restrictions. Authorization must operate at the individual record level, evaluating data values dynamically at query execution time.

Omnismith has expanded its role-based access control (RBAC) engine to support row-level "Access Scopes." This addition complements the existing module-based and resource-based security permissions by applying granular, value-driven constraints directly to database operations.

Architecture of Omnismith Access Controls

The security model of Omnismith operates across three distinct tiers. Every role defined in a project is evaluated against these tiers during API requests.

Module-Based Access: The outer security layer. It controls access to entire functional zones within the platform, such as Attribute Management, Template Management, Entity Management, Billing, or Automation. Each module supports four basic operational levels: View, Create, Edit, and Delete.
Resource-Based Access: The structural security layer. This level regulates permissions for specific templates or attributes. An administrator can assign Full Access, Edit, View Only, or Deny permissions to specific structures. This layer enables the hiding of sensitive fields containing personally identifiable information (PII) or entire entity groups from unauthorized roles.
Access Scopes (Row-Level): The data-level security layer. Access Scopes target individual entities inside a template. These scopes apply dynamic, conditional rules to determine if a specific role can view or manipulate a specific entity.

Roles in Omnismith remain strictly project-scoped. Consequently, the newly introduced Access Scopes are assigned, stored, and executed within the boundary of a single project role.

Design of Row-Level Access Scopes

An Access Scope is bound to a single template and contains one or more conditions. Each condition compares an attribute value on the target entity with a static or dynamic value defined in the role configuration.

The evaluation logic scales from basic scalar matching to complex relational checks:

String Conditions: The simplest form of row filtering. For example, a role designed for a billing team can be restricted on the Team Members template. The Access Scope evaluates the Team string attribute, permitting access only to records matching the value "Billing".
List Conditions: These evaluate values against set options or statuses, ensuring a user only accesses records assigned to appropriate phases of a workflow.
Reference Conditions: These resolve references to other entities in the system. In a Cold-Chain Fleet Management project utilizing a Shipments template, an Access Scope can restrict a delivery driver to specific rows. The configuration validates whether the Driver reference attribute on the shipment entity matches the unique identifier of the driver's own entity (e.g., "Bob Smith") in the Drivers template.

// Schematic example. Please check OpenAPI Spec for actual schema definitions.
{
  "template_uuid": "018f3a3c-5d7a-7c65-8f5a-3c5d7a658f5a",
  "conditions": [
    {
      "attribute": "driver_reference",
      "operator": "equals",
      "value": "018f3a3c-5d7a-7c65-8f5a-3c5d7a658f5b"
    }
  ]
}

To support complex business rules, users can attach multiple Access Scopes to the same template within a single role. When multiple scopes are defined for the same structure, the query engine treats them as logical OR conditions. This allows a user to access rows matching predicate A or predicate B, avoiding restrictive narrow filters when broader visibility is required.

Database-Level Compilation and CQRS Integration

Evaluating row-level permissions in application memory introduces severe scaling bottlenecks. Fetching entire datasets to filter them inside the runtime consumes excessive memory and CPU cycles.

Omnismith bypasses application-level filtering by compiling Access Scopes directly into the database layer. The platform relies on a CQRS (Command Query Responsibility Segregation) model for read operations. When a query is initiated through the API, the query handler inspects the active project session, retrieves the active role's Access Scopes, and compiles the conditions into native SQL.

These compiled conditions are dynamically appended to the query. For simple attribute filters, the compilation produces basic comparison clauses:

WHERE attribute_value = parameter

For complex reference conditions, the compiler resolves the relations to ensure the reference identifiers match. By modifying the execution AST (Abstract Syntax Tree) before query execution, the database optimizer can use existing indexes on attributes and entity relationships. The security boundary is enforced natively by PostgreSQL at the storage layer, ensuring that unauthorized records are never loaded into the application context.

Performance Tradeoffs and Database Profiling

While compile-time query filtering preserves system memory, it shifts the computational load to the PostgreSQL query planner. Appending multiple dynamic clauses and complex relational subqueries can alter index selection paths.

The platform structures tables on PostgreSQL and TimescaleDB with highly optimized indexing strategies designed to handle dynamic EAV (Entity-Attribute-Value) attributes. However, highly nested logical OR blocks combined with deep entity references may introduce planning overhead on projects with vast datasets.

Omnismith monitors query performance and has designed these access paths to prevent degradation under standard workloads. To encourage comprehensive testing of this architecture, Omnismith is running an optimization challenge: the first tenant to encounter, document, and submit a verifiable database-side query execution degradation caused by Access Scope complexity will receive a discount on their monthly subscription.

Security Posture

The addition of Access Scopes provides a unified mechanism for coarse and fine-grained data isolation. Because the filtering mechanism is integrated into the core CQRS database execution pipeline, security boundaries remain uniform across the interactive web application, API endpoints, automated workflows, and AI Assistant actions.

AI Tool-Calling: Translating Business Requirements to Database Schemas

HomelessCoder — Sun, 12 Jul 2026 19:51:07 +0000

Part 2 of the Omnismith "Core Platform Capabilities" series

Integrated AI assistants can map natural language schema requirements to operational APIs, deploying complete database schemas and demo datasets in real time.

The initial setup of an entity database with integrated telemetry requires substantial manual configuration. Developers building solutions for clients and technical operators bootstrapping operations must define schema structures, configure API endpoints, and establish relational integrity between physical assets and time-series logs before a single metric can be ingested. This initialization phase delays functional deployment and increases setup friction.

Omnismith addresses this setup delay by exposing its backend OpenAPI specification directly to an integrated AI Assistant. This architecture allows the assistant to interpret structured schema requirements written in natural language, map them to operational API endpoints, and deploy completed schemas on a blank project in real time.

The AI-Assisted Cold-Chain Fleet Management Schema

To bypass this manual boilerplate, a user can submit a single, plain-text request directly to the Omnismith AI Assistant interface:

"Create a fleet management schema with Vehicles, Shipments, and Drivers. Link shipments to vehicles and drivers, and track temperature and fuel metrics on vehicles."

The AI Assistant directly parses this requirement, coordinates the dependent operations, and executes the necessary API calls in sequence against the live platform.

Step 1: Automated Model Scaffolding

Upon receiving the prompt, the assistant acts as a high-level database orchestrator. It immediately identifies the three primary entities: Vehicles, Drivers, and Shipments.

To minimize network overhead, the assistant calls a consolidated system orchestration tool, scaffold_data_model, to register the core templates and their initial properties inside the dynamic Entity-Attribute-Value (EAV) database:

Vehicle Generation

The assistant identifies the requirement to track identity, model, fuel, and temperature. It packages these into the first scaffold payload:

Tool: scaffold_data_model
Payload:

{
  "templateName": "Vehicle",
  "attributes": [
    {"name": "Vehicle ID", "type": "text"},
    {"name": "Make/Model", "type": "text"},
    {"name": "Fuel Level", "type": "number"},
    {"name": "Temperature", "type": "number"}
  ]
}

Driver Generation

The assistant scaffolds the profile template required to represent staff records:

Tool: scaffold_data_model
Payload:

{
  "templateName": "Driver",
  "attributes": [
    {"name": "Driver Name", "type": "text"},
    {"name": "License Number", "type": "text"}
  ]
}

Shipment Generation

The assistant maps out the shipment record structure, registering placeholders for relational references pointing to the driver and vehicle:

Tool: scaffold_data_model
Payload:

{
  "templateName": "Shipment",
  "attributes": [
    {"name": "Shipment ID", "type": "text"},
    {"name": "Destination", "type": "text"},
    {"name": "Assigned Vehicle", "type": "reference"},
    {"name": "Assigned Driver", "type": "reference"}
  ]
}

Step 2: Closed-Loop Validation and Refinement

Omnismith utilizes a closed-loop validation engine. To verify complete execution, the assistant reads the newly deployed schema back from the platform and evaluates it against the logical requirements.

This verification pass ensures structural and temporal properties are precisely configured before telemetry ingestion begins. The assistant executes a target refinement step:

Telemetry Metric Promotion: The initial scaffolding pass registered the Fuel Level and Temperature fields as baseline numerical attributes. To support high-frequency time-series chart streaming, the validation loop promotes both fields to telemetry-optimized metric fields (data_type: 1).

Step 3: Establishing Referential Integrity

With clean template shapes in place, the assistant completes the schema by weaving the logical connections between the templates.

It maps the dynamic reference parameters on the Shipment template, instructing the relational system to look up concrete, real-time records from the Vehicle and Driver registries:

Vehicle Link: The assistant maps the Assigned Vehicle reference attribute directly to the display attribute of the target Vehicle template.
Driver Link: The assistant repeats the relational mapping for the operator records.

Because the Omnismith database engine runs on a fully dynamic runtime schema, these alterations execute instantly with no physical database migration files, zero downtime, and zero manual endpoint compilation.

Structural and Behavioral Tradeoffs

Conversational schema scaffolding trades absolute, deterministic predictability for rapid development speed.

When developers write declarative ORM schemas, migration scripts, or JSON configuration models, the resulting environment matches the written code exactly. When relying on an LLM-driven assistant, overly descriptive instructions or grammatical nuances can sometimes require structural verification passes.

To offset these behavioral risks, Omnismith relies on two structural guardrails:

Closed-Loop Verification: The agent continuously diffs the deployed API state against the intended design model, using targeted calls to refine structural details on the fly.
Visual Verification Layer: The resulting schema displays immediately in the web application's Template Library and Attribute Library. This allows developers to manually tune specific relationship constraints, tweak validation parameters, or tighten boundary conditions before ingesting operational telemetry.

Populating the Schema: Conversational Entity Ingestion

With the database structure actively running, the AI Assistant can manage concrete records within the newly established dynamic templates. Operators can query, analyze, and seed the environment.

To prepare the environment for operational testing, a user can submit a direct request to populate the fleet system:

"Generate realistic demo data for this project. Requirements: minimum 5 drivers, 7 vehicles, and 4 shipments. Ensure the dataset reflects diverse business scenarios and edge cases"

Because shipments contain strict relational constraints—requiring references to physical vehicles and registered drivers—the AI Assistant cannot execute these creations as a single batch. It coordinates a logical multi-step deployment strategy shown in the interface trace:

Independent Ingestion: The assistant first registers the independent primary resources. It calls create_entity 12 consecutive times to instantiate 5 unique driver profiles and 7 physical fleet vehicles with varied baselines.
Reference Resolution: To link the upcoming shipment logs to these exact entries, the assistant executes 2 calls to search_entities. This returns the dynamic database state, mapping the human-readable driver names and vehicle license IDs to their platform-generated UUIDv7 keys.
Relational Ingestion: With the required reference keys resolved, the assistant executes the final 4 create_entity calls. This populates the Shipment records, mapping individual waybills to the resolved vehicle and driver identifiers while introducing complex logistics parameters (such as sub-zero frozen cargo targets and baseline fuel levels).

The resulting records populate the system instantly, providing technical operators with a functional sandbox that models actual business environments.

Omnismith, AI Assistant, Creating Records Using Natural Language

Omnismith, Vehicle Template, Entity Search Page

Omnismith, Vehicle Entity Quick Edit Dialog

Omnismith, Vehicle Entity Audit Log

Operational Readiness

The finalized schema produces an immediately queryable, typed database structure. Every template and attribute is initialized with a distinct, immutable UUIDv7. The platform is ready to accept ingestion streams and transactional updates immediately:

Real-time Ingestion: Temperature sensors mounted on fleet assets can start streaming sensor metrics straight to the platform's high-volume metric stream using the endpoint: POST /v1/entities/{entity_id}/metrics. This bypasses the primary document update path, sending values directly to TimescaleDB for sub-second chart visualization.
Relational Search Queries: The query engine natively resolves the references established by the assistant. Operators can run complex queries to filter all active Shipment entities associated with a specific vehicle ID where the vehicle state is flagged as active.
Audit Trailing: Any change to these attributes is continuously written to an append-only transaction ledger on TimescaleDB, detailing what changed, when, and by whom from the first second of deployment.

The cold-chain fleet management model developed in this guide illustrates how natural language requirements map directly to relational schemas and telemetry databases. While built for logistics, these same AI-driven scaffolding and conversational ingestion mechanics apply to any operational domain, from facility management to hardware infrastructure tracking.

In the next entry of this series, the platform will utilize this active cold-chain database to demonstrate dynamic automations, configure multi-role access controls (RBAC/ABAC), and build real-time monitoring dashboards.

The Manual REST Alternative

To understand how the AI Assistant automates schema deployment, it is valuable to look at how a developer constructs this exact environment manually. Under the hood, Omnismith exposes structured REST endpoints to register templates and attributes dynamically at runtime.

In a traditional development cycle, creating this cold-chain fleet management schema requires sequentially executing a series of dependent API requests.

1. Creating the Templates

First, the developer must register empty template containers for each operational concept:

POST /v1/templates HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Vehicle",
  "description": "Fleet assets equipped with environmental sensors"
}

This returns a template identifier (e.g., 019f51bf-366c-72b9-94e1-0435af01e34a), which must be recorded to associate attributes in subsequent steps.

2. Registering Attributes

Next, individual attributes must be registered and attached to their templates. For instance, creating the high-frequency environmental telemetry attribute Temperature requires specifying its metric type and numerical data type:

POST /v1/attributes HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "name": "Temperature",
  "attribute_type": 1,
  "data_type": 1,
  "template_ids": ["019f51bf-366c-72b9-94e1-0435af01e34a"]
}

3. Establishing References

Finally, the developer must configure relational integrity for reference fields—such as linking a shipment to its assigned driver—by updating the reference configuration on the respective attribute:

PUT /v1/attributes/019f51bf-3a42-71a3-95db-3736a6ad980b/reference HTTP/1.1
Host: api.omnismith.io
Content-Type: application/json
Authorization: Bearer <token>

{
  "target_template_id": "019f51bf-3836-71a9-a8d7-d5365ee60f3d",
  "target_attribute_id": "019f51bf-373f-714f-a811-7d983da1206f"
}

While these endpoints offer complete control, building a full relational schema manually requires tracking numerous UUID dependencies and drafting boilerplate payloads.

Scaffolding Business Domain Models with Dynamic Schemas

HomelessCoder — Sun, 12 Jul 2026 19:40:09 +0000

This article kicks off our new "Core Platform Capabilities" series

Operational platforms require structured data, but rigid database schemas slow down development. Omnismith uses a runtime EAV model to let schemas evolve alongside the business.

Operational platforms require structured data to track physical assets, inventory, or internal resources. Traditional relational databases mandate rigid schema definitions. Altering these schemas to accommodate new business requirements introduces migration files, application deployments, and potential database downtime.

Omnismith resolves this constraint by implementing a dynamic schema architecture based on the Entity-Attribute-Value (EAV) model. This structure permits runtime modifications to the domain model without altering the underlying database tables.

The Three Foundational Components

The platform divides domain modeling into three foundational components: Attributes, Templates, and Entities.

Attributes function as field definitions. They enforce data types and structural constraints. An attribute can be configured as a dimension (representing structural properties like strings, booleans, or dates), a metric (recording time-series values), a list (providing enumerated options), or a reference (linking to other entities).
Templates act as reusable schemas. A template groups specific attributes to define the shape of a business object. For example, a template representing server infrastructure might group a hostname string attribute, an environment list attribute, and a CPU utilization metric attribute.
Entities are the instantiated records. Every entity belongs to a template and populates the predefined attributes with explicit values.

Querying and Performance Tradeoffs

This architecture introduces a specific tradeoff. Querying an EAV structure requires more complex SQL operations than querying a flat relational table. Omnismith manages this complexity internally, exposing a unified entity search interface that supports filtering, sorting, and pagination without exposing the underlying table structure to the user.

Runtime Schema Evolution

The resulting system allows users to define custom business domains, group properties into templates, and deploy them to active projects instantly. Data structures are modeled and populated entirely at runtime, allowing the data model to evolve alongside the business.

Self-Hosting Prometheus and Grafana for Omnismith (For Now)

HomelessCoder — Sun, 28 Jun 2026 16:05:51 +0000

When building a data-intensive platform, real operational visibility becomes necessary quickly. A core API might be fast, but if event consumers lag or the database strains, the system degrades.

The industry reflex is often to reach for a managed SaaS provider or immediately start instrumenting the codebase with OpenTelemetry. But for an early-to-mid-stage project, SaaS ingest pricing can rapidly drain a budget, and app-level instrumentation can be a distraction when basic infrastructure baselines do not yet exist.

A pragmatic, battle-tested standard provides a solution: a self-hosted stack using Prometheus, Grafana, and dedicated Exporters.

Here is a look at the architecture, the tradeoffs, and why this is the right "Phase 1" approach for scaling platforms.

Observing Infrastructure Directly

Before instrumenting application-level spans and traces, a platform first needs a bedrock of infrastructure visibility. By starting with the underlying state and event layers (PostgreSQL and Kafka), a decoupled pipeline for system health is established.

Omnismith relies on robust foundational infrastructure. This separation of concerns keeps the application fast and reliable, but it introduces operational complexity. If the database experiences heavy query load or if Kafka consumers fall behind, the platform's performance degrades.

By collecting metrics directly from the infrastructure itself using postgres-exporter and kafka-exporter, a baseline of operational health is established that complements future application-level telemetry.

Architecture and Extensibility

By combining Prometheus with dedicated infrastructure exporters, robust telemetry is achieved without adding latency to the primary request path or polluting the application domain.

+------------------+                         +------------------+
|    PostgreSQL    |                         |   Apache Kafka   |
|    (Database)    |                         |    (Event Bus)   |
+------------------+                         +------------------+
          |                                            |
          v                                            v
+------------------+                         +------------------+
|     Postgres     |                         |       Kafka      |
|     Exporter     |                         |      Exporter    |
+------------------+                         +------------------+
          |                                            |
          |           +------------------+             |
          +---------> |    Prometheus    | <-----------+
                      | (Scrape & Alert) | 
                      +------------------+
                                |
                                v
                      +------------------+
                      |     Grafana      |
                      |   (Dashboards)   |
                      +------------------+

Each component fulfills a specific operational boundary:

Exporters: Run alongside the core infrastructure, exposing internal metrics (e.g., table sizes, partition counts, consumer group lag) over HTTP.
Prometheus: Periodically scrapes these exporters, maintains time-series data, and evaluates recording rules to trigger alerts.
Alerting & Visualization: Alerts are routed to communication channels via Grafana Alerting to avoid active dashboard monitoring. Grafana also queries Prometheus to provide unified, real-time visualization.

This design is highly extensible. As infrastructure complexity grows, additional metrics can be collected by simply provisioning new exporters and adding them as Prometheus scrape targets.

The TCO Tradeoff: Financial Efficiency vs. Maintenance

In the early and growth phases of a platform, infrastructure decisions require a balance between operational capability and financial discipline.

Deploying and managing a self-hosted observability stack rather than relying immediately on managed cloud SaaS providers yields two major advantages:

1. Direct Financial Efficiency

Managed monitoring solutions often carry steep pricing structures linked to ingested data volume.

While self-hosting requires engineering time to maintain, avoiding the steep data-ingest pricing drastically reduces direct cash burn in the early stages. Accepting the trade-off that self-hosting a stateful time-series database introduces its own maintenance burden (such as managing storage retention) is necessary. However, at current platform volumes, the financial savings vastly outweigh the operational overhead, directly extending runway.

2. Deep Platform Understanding

Operating complex distributed infrastructure hands-on builds essential domain expertise.

Configuring Prometheus scrape intervals, understanding exporter metrics, and provisioning Grafana dashboards provides deep visibility into low-level system mechanics. When the platform eventually scales to warrant managed cloud instances (such as AWS Managed Prometheus), the transition can be executed efficiently with an exact understanding of system requirements.

Conclusion

By monitoring the foundational infrastructure directly and operating an efficient self-hosted stack, the platform gains an extensible observability layer and significant cost savings during a critical growth phase. Application instrumentation is definitely next, but this infrastructure baseline had to come first.

Building a Blueprint Marketplace for Reusable Project Structures

HomelessCoder — Tue, 07 Apr 2026 21:07:20 +0000

Flexible platforms create repeated modeling work.

I saw that clearly while building Omnismith. Users can model their own business domains with templates, attributes, references, and entities. Many of those domains still start from similar structures.

Product catalogs, asset tracking, server monitoring, and CRM-style workflows use different labels and fields. They still reuse many of the same structural ideas.

That observation led to the Blueprint Marketplace.

Repeated domain work

Flexible platforms give users room to model their own systems. They also push a lot of design work onto each new workspace.

When the same structures are rebuilt in one workspace after another, that is repeated setup cost.

It also keeps useful ideas trapped inside isolated projects.

If one team has already designed a strong starting structure for a product catalog, a monitoring workspace, or a roadmap tracker, the product should make that reusable. Otherwise every new project starts by rediscovering work that was already done.

Omnismith needed a way to turn repeated domain modeling into reusable project structures.

Why "Template Marketplace" was not enough

The first internal name for this was Template Marketplace.

The name was too narrow.

A template is only one piece of what makes a project usable. A real starting point usually includes several templates, multiple attributes, references between models, and a set of decisions about how those pieces fit together. Publishing templates alone would expose fragments. I needed a way to package and publish a coherent project structure.

That is why the concept became Blueprint Marketplace.

The term “blueprint” covered the larger unit more accurately. It described a reusable structure that could be installed into another project and still make sense.

The publication boundary mattered early

The most important constraint was safety.

I wanted users to publish reusable structures. I also needed a clear guarantee that the marketplace would not expose actual project records.

That boundary shaped the model early.

User-published blueprints carry reusable definitions. They do not carry live business data. Featured blueprints are curated and reviewed before they appear in onboarding or other product-controlled surfaces.

That distinction made the marketplace usable as both a user-facing feature and an internal product distribution channel.

The implementation started from an existing example

The Product Catalog dataset had already been written in code with reuse in mind.

That reduced the amount of conceptual redesign. The real work was everything around it: persistence, publication flow, API support, and UI support.

I started with console support because it was the fastest way to exercise the publishing model and test the rules around what a blueprint could contain. That gave the rest of the implementation a clearer contract.

Why this changes the product

The Blueprint Marketplace changes how Omnismith can evolve as a platform.

reusable structures can be installed into new projects
useful domain knowledge becomes portable inside the product
curated official blueprints can guide important product flows
onboarding and starter experiences can reuse the same underlying publication system

Once reusable blueprints exist as a first-class capability, onboarding does not need to depend on special-case demo logic forever. The same system that supports marketplace publishing can also support official starter projects and curated first-session paths.

Final thought

The Blueprint Marketplace started from a simple product observation: flexible platforms still accumulate repeated domain work.

I did not want Omnismith users to keep rebuilding the same project structures in isolation. I wanted those structures to become publishable, installable, and reusable inside the product itself.

That made the marketplace worth building on its own. It also created the foundation for the onboarding work that came after it.

DEV Community: HomelessCoder

Introducing the Omnismith MCP Server: Connect Claude Desktop & Cursor with One-Click OAuth

Why Connect Your AI Assistant to Omnismith via MCP?

One-Click OAuth Connection

Getting Started

Zero-Code AI Agent Observability: Auditing Claude Desktop & MCP Tool Calls with Omnismith

The Desktop AI Observability Blindspot

Architectural Evolution: Designing an Honest, High-Signal Schema

1. Swapping latency_ms for Qualitative Duration Buckets

2. Domain-Agnostic Relational Grounding (resource_type + resource_id)

3. Workflow Correlation with session_id

4. Categorization & Failure Diagnostics

The Omnismith ai_agent_execution Schema

Step-by-Step: Enabling Observability in Claude Desktop

Step 1: Connect the Omnismith Custom Connector

Step 2: Ask Claude to Create the ai_agent_execution Schema

Step 3: Configure the Prompt Directive

Step 4: Execute & Observe

Dogfooding in Action: The Self-Auditing Assistant

Conclusion

Omnismith Engineering Telegram Channel

How I Track Website Demo Requests with Omnismith (and Instant Telegram Alerts)

Workflow Overview

1. Defining the Data Model

2. Ingesting Form Submissions via REST API

3. Centralized Lead Records Dashboard

4. Configuring Real-Time Telegram Alerts

Step A: Register the Telegram Notification Channel

Step B: Create the Automation Rule

Step C: Format the Alert Message

The Outcome: Instant Notifications for Every Lead

Key Implementation Considerations

Summary

Extending Slugs Across Templates and Entities for Deterministic API Workflows

The Problem with UUID-Only Ingestion

Architecture of Universal Slug References

End-to-End API Sequence

Technical Tradeoffs

System Impact

Configuring Event-Driven Automations and Telegram Notifications

Configuring Notification Channels

Verifying Channel Connectivity

Defining Event-Driven Automations

Managing Execution Frequency with Cooldowns

Deploying a Temperature Excursion Automation

Dynamic Message Template Interpolation

Execution Audit and Log Evaluation

Architectural Performance Tradeoffs

Ingesting Real-Time Telemetry and Configuring Observability Dashboards

Isolated Ingestion Pipelines

The Ingestion Payload

Real-Time Telemetry Automation in Action

Building the Observability Layer

Configuring Dashboard Blocks Programmatically

1. Monitoring Fleet Status with Stat Blocks

2. Safeguarding Temperature with Gauge Blocks

3. Analyzing Fuel Trends with Chart Blocks

Runtime Computation Layer

Architectural Performance Tradeoffs

Implementing Row-Level Access Control

Architecture of Omnismith Access Controls

Design of Row-Level Access Scopes

Database-Level Compilation and CQRS Integration

Performance Tradeoffs and Database Profiling

Security Posture

AI Tool-Calling: Translating Business Requirements to Database Schemas

The AI-Assisted Cold-Chain Fleet Management Schema

Step 1: Automated Model Scaffolding

Vehicle Generation

Driver Generation

Shipment Generation

Step 2: Closed-Loop Validation and Refinement

Step 3: Establishing Referential Integrity

Structural and Behavioral Tradeoffs

Populating the Schema: Conversational Entity Ingestion

Operational Readiness

The Manual REST Alternative

1. Creating the Templates

2. Registering Attributes

3. Establishing References

1. Swapping `latency_ms` for Qualitative `Duration` Buckets

2. Domain-Agnostic Relational Grounding (`resource_type` + `resource_id`)

3. Workflow Correlation with `session_id`

The Omnismith `ai_agent_execution` Schema

Step 2: Ask Claude to Create the `ai_agent_execution` Schema