Skip to content

docs(content): one h1 per docs page — 137 deletions, 16 demotions, and a gate#12262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
os-zhuang merged 2 commits into from
Aug 25, 2026
Merged

docs(content): one h1 per docs page — 137 deletions, 16 demotions, and a gate #12262

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0a83c42
docs(content): drop the duplicate body H1 from 153 hand-written pages
os-zhuang Aug 25, 2026
274e157
chore(scripts): add check:docs-single-h1 so a body h1 cannot come back
os-zhuang Aug 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions .github/workflows/lint.yml
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -1071,6 +1071,32 @@ jobs:
- name: Docs anchors resolve to real headings
run: pnpm check:doc-anchors

# #12236 one <h1> per doc page. `DocsTitle` renders the frontmatter `title`
# as the page's <h1> unconditionally (apps/docs/app/[lang]/docs/[[...slug]]/
# page.tsx), so a body-level `# ` heading compiles to a SECOND one inside
# `DocsBody`. Measured on the dev server at /docs/data-modeling/objects
# before the sweep: two <h1>, both reading "Object Metadata". 195 of the 403
# pages were in that state, 138 of them with the two <h1> identical.
#
# It lives next to check:doc-anchors because the two share the corpus and
# the heading model — this gate imports `stripFrontmatter` and
# `flattenHeadingText` from that one rather than re-modelling either, which
# is what makes the delete-vs-demote remedy right on the nine pages whose
# two headings differ only by inline code markup.
#
# The gate strips FENCED CODE before looking for a heading, and that is the
# load-bearing half: a naive `^# ` scan reports 205 files, ten of which are
# shell/YAML comments inside working examples. A fence-blind rule does not
# over-report by ten, it instructs the fixer to corrupt ten snippets.
#
# Two subtrees are excluded, each with a named owner (#12249 generated
# reference pages, #12250 release notes) and each self-retiring: the gate
# FAILS with DEAD-EXCLUSION when an excluded tree becomes clean, so the
# carve-outs cannot outlive their reasons. A run that judges zero pages
# fails too (#4690).
- name: One `<h1>` per docs page
run: pnpm check:docs-single-h1

# #9014 docs redirects: `apps/docs/redirects.mjs` is a 92-entry table of
# PERMANENT (308) redirects, and before this step nothing in the repo read
# it — `dispatch-gates.mjs apps/docs/redirects.mjs` named no family over 99
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/actions-as-tools.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Actions as Tools
description: Expose declarative Action metadata as AI-callable tools with explicit opt-in, HITL approval, and permission-aware execution
---

# Actions as Tools

Part of the [AI module](/docs/ai) — how existing Action metadata becomes LLM-callable, and the guardrails around it.

This is what makes the app you built **AI-operable**: connect an MCP client (Claude Code, Cursor, …) and your business Actions become callable tools — so an agent can "resolve this ticket" or "convert this lead" through the same logic and permissions as the Console button.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/agents.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: AI Agents
description: The two platform agents (ask and build), how skills extend them, and the shape of an AgentSchema record
---

# AI Agents

Part of the [AI module](/docs/ai). In the **open edition**, agents, tools, and
skills are **typed metadata**. You author **skills** (`defineSkill`) — agents are
platform-owned and tool records are optional (see below) — from the open
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/connect-mcp.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Connect an MCP Client
description: Point Claude Code, Claude Desktop, or any MCP client at your running app — OAuth or API key — and verify the agent can see and operate it.
---

# Connect an MCP Client

Every ObjectStack deployment is already an MCP server. The runtime serves the
[Model Context Protocol](https://modelcontextprotocol.io) at **`/api/v1/mcp`**
— on by default, no plugin to install, no configuration step. Your objects and
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/index.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: AI Overview
description: Complete guide to leveraging AI agents, RAG pipelines, and intelligent automation in ObjectStack
---

# AI Overview

AI in ObjectStack is a **cross-protocol capability layer**: agents, tools, and knowledge retrieval sit on top of the same objects, actions, permissions, and automation that power the rest of the platform. This module covers the architecture and each of its moving parts.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/knowledge-rag.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Knowledge & RAG
description: The Knowledge Protocol — permission-aware RAG for agents via pluggable adapter plugins (memory, RAGFlow, custom)
---

# Knowledge & RAG

Part of the [AI module](/docs/ai) — how agents retrieve knowledge through the Knowledge Protocol and its adapter plugins.

ObjectStack ships a Knowledge Protocol that lets you retrieve from pluggable backends (RAGFlow, LlamaIndex, Dify, custom pgvector, …) with one call: `KnowledgeService.search(query, { sourceIds?, topK? })`. The framework defines the contract and runs permission-aware filtering; the adapter plugin does the actual retrieval. See [the protocol design](/docs/protocol/knowledge) for the rationale.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/natural-language-queries.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Natural Language Queries
description: How agents query live data through the open MCP data tools (query_records, get_record, aggregate_records) under RLS
---

# Natural Language Queries

Part of the [AI module](/docs/ai) — how natural-language questions become ObjectQL queries at runtime.

Natural-language querying is **open**. Point your own AI — Claude, Cursor, any
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/skills-reference.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: AI Skills Reference
description: Reference for every ObjectStack AI skill — domain-scoped knowledge modules that teach AI assistants the protocol's schemas and constraints
---

# AI Skills Reference

ObjectStack ships a set of **domain-specific skills** that teach AI assistants (Claude Code, GitHub Copilot, Cursor, …) the protocol's schemas, patterns, and constraints — plus **process** skills that teach how work moves through a project rather than what to author. This guide is the complete catalog.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/skills.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,8 +5,6 @@ description: How ObjectStack uses structured AI skills to enable intelligent cod

import { Bot, Brain, Cpu, Database, Globe, Layout, Shield, Workflow, Wrench, Languages, Zap, Puzzle, BookOpen, Target, ArrowRight } from 'lucide-react';

# AI Skills System

ObjectStack introduces a **Skills System** — structured, domain-specific knowledge modules that enable AI assistants (GitHub Copilot, Claude Code, Cursor, etc.) to understand and generate protocol-compliant code. Skills are what make [building with Claude Code](/docs/getting-started/build-with-claude-code) reliable: they teach the agent the protocol's rules up front, so it authors correct metadata instead of guessing.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/ai/tools.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Tool Records
description: The three ways a capability reaches an agent, and the narrow case where authoring a tool record is the right answer
---

# Tool Records

Part of the [AI module](/docs/ai). `tool` is an authorable metadata kind —
`ToolSchema`, declared as `defineStack({ tools })` — and it is the **least
likely** answer to "how do I give my agent a new capability".
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/client-sdk.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Client SDK
description: The official TypeScript client for ObjectStack — auto-discovery, typed metadata, CRUD, batch operations, and service-aware feature detection.
---

# Client SDK

The `@objectstack/client` is the official TypeScript client for ObjectStack. It provides a typed, protocol-aware interface that automatically adapts to your server's available services.

## Features
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/data-api.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Data API
description: REST endpoints for CRUD, batch operations, record cloning, and analytics queries.
---

# Data API

Record CRUD, batch operations, and analytics queries over REST. All paths are relative to the base URL (defaults to `/api/v1`) — see the [API Overview](/docs/api) for discovery and service availability.

## Data Operations
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/data-flow.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Data Flow Diagrams
description: How data moves through the ObjectStack system — from defineStack() configuration to database queries, realtime events, and metadata resolution
---

# Data Flow Diagrams

This guide provides detailed diagrams showing how data moves through every layer of the ObjectStack system — from developer configuration to database operations and back to the client.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/declarative-endpoints.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Declarative Endpoints
description: "Expose your app to systems outside the platform by declaring an apis: endpoint as metadata — which channel to pick, the four publish gates, and the obligation that comes with an anonymous endpoint."
---

# Declarative Endpoints

A stack can publish an HTTP endpoint as **metadata** instead of writing a handler: a URL,
a method, a policy block, and the pipeline it delegates to. That is the `apis:` block of
`defineStack`, and its entries are **live from protocol 17** — an endpoint that passes its
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/environment-routing.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Environment-Scoped Routing
description: Route REST, metadata, automation, AI, and package calls through /api/v1/environments/:environmentId/....
---

# Environment-Scoped Routing

Environment-scoped routing makes the target runtime explicit in the URL:

```text
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/error-catalog.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Error Code Catalog
description: Complete reference for all ObjectStack error codes with causes, fixes, and retry strategies
---

# Error Code Catalog

ObjectStack uses a structured error system with **9 error categories** and **50 standardized error codes**. Every error includes a machine-readable code, HTTP status mapping, and retry guidance.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/error-handling-client.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Client-Side Error Handling
description: Best practices for handling ObjectStack errors in client applications — parsing, display, retry strategies, and React patterns
---

# Client-Side Error Handling

This guide covers best practices for handling ObjectStack API errors in client applications — from parsing error responses to displaying validation errors in forms and implementing retry strategies.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/error-handling-server.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Server-Side Error Handling
description: Best practices for handling and throwing errors in ObjectStack plugins — custom errors, hook propagation, validation, transactions, and safeParsePretty
---

# Server-Side Error Handling

This guide covers best practices for handling and throwing errors within ObjectStack plugins and server-side code — from creating custom errors with proper codes to transaction rollback and integration with `safeParsePretty()`.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/index.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: API Overview
description: How ObjectStack generates its API surface from metadata — discovery, error handling wire formats, protocol types, and a map of the API & SDK docs.
---

# API Overview

ObjectStack generates its entire API surface — REST endpoints, realtime protocols, and the client SDK — from your metadata: define an object once and its endpoints exist. This module documents those surfaces and how to consume them.

ObjectStack exposes a fully typed REST API. All endpoints use JSON request/response bodies. The API is **service-driven** — routes are only available when the corresponding plugin is installed. Use the [Discovery endpoint](#discovery) to determine what services are available at runtime.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/metadata-api.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Metadata & Package API
description: REST endpoints for object schemas, metadata types, UI views, and package management.
---

# Metadata & Package API

Manage object schemas, metadata types, UI views, and installed packages over REST. All paths are relative to the base URL (defaults to `/api/v1`) — see the [API Overview](/docs/api) for discovery and service availability.

## Metadata
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/plugin-endpoints.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Plugin Endpoints
description: REST endpoints that become available when the corresponding plugin is installed — auth, workflow, automation, views, realtime, notifications, AI, i18n, and file storage.
---

# Plugin Endpoints

These REST endpoints are only available when the corresponding plugin is installed. Check the [discovery manifest](/docs/api#discovery) `services` map before calling them; all paths are relative to the base URL (defaults to `/api/v1`).

This page is a **catalog of routes the platform serves for you** — it is not about authoring an
Expand Down
2 changes: 0 additions & 2 deletions content/docs/api/wire-format.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Wire Format & JSON Examples
description: Complete HTTP request/response examples for ObjectStack API operations — CRUD, queries, metadata, errors, and batch operations
---

# Wire Format & JSON Examples

This page provides complete HTTP request and response examples for every common ObjectStack API operation. All examples use a `task` object with realistic data.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/approvals.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Approval workflow
description: Route a record for sign-off — who can configure the automation, and the run-identity decision that keeps an approval flow from quietly bypassing row-level security.
---

# Approval workflow

## Scenario

> A record (an invoice, a discount, a leave request) must be **routed for approval** before it proceeds. Who is allowed to build that automation, and how do I make sure it runs safely?
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/connectors.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Connectors
description: Call external systems from flows — plugin-registered connectors, and declarative provider-bound instances (rest / openapi / mcp) authored as pure metadata with reference-based credentials.
---

# Connectors

> **Status:** Shipped · **Audience:** App authors (human and AI), integration
> engineers
>
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/email-templates.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Email Templates
description: Author a localizable outbound mail template as metadata, and reach it from a flow's notify node or from services.email.
---

# Email Templates

An **email template** is a named, localizable subject + body that lives as
metadata. Your app declares it; the email service resolves it by
`(name, locale)` at send time and renders its `{{placeholders}}` against a
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/flows.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Flow Metadata
description: Build visual automation with decision trees, data operations, HTTP requests, and screen interactions
---

# Flow Metadata

A **Flow** is a visual automation that orchestrates business logic through connected nodes. Flows support decision branching, data operations (CRUD), HTTP integrations, script execution, user screens, and subflow composition.

## Basic Structure
Expand Down
2 changes: 1 addition & 1 deletion content/docs/automation/hook-bodies.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,7 +3,7 @@ title: Hook & Action Bodies (L1 / L2)
description: How hook handlers and script-action bodies travel through ObjectStack as pure metadata, and the spec they must conform to.
---

# Hook & Action Bodies
## Hook & Action Bodies

ObjectStack treats every hook handler and every `type: 'script'` action as **pure metadata**. In the self-contained (body-only) form there is no separate `.mjs` file shipped alongside the project artifact, no dynamic `import()` at runtime, and no filesystem dependency on the cloud — though today a legacy `objectstack-runtime.{hash}.mjs` back-compat bundle can still ship, and does get dynamically imported at boot, for any handler that hasn't been lowered to a metadata `body` yet (see [Migration](#migration) below). A body is either:

Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/hooks.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Hooks
description: Run custom code at interception points in the ObjectQL execution pipeline — before/after insert, update, delete, and find
---

# Hooks

Hooks are the data-layer "logic layer": they run custom code at interception
points in the ObjectQL execution pipeline (before/after insert, update, delete,
find, etc.). The construct is `Hook`, imported from `@objectstack/spec/data`.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/index.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Automation
description: Hooks, flows, workflows, approvals, scheduled jobs, durable webhooks, and connectors — the process engine that reacts to your data.
---

# Automation

Automation is ObjectStack's process engine: you attach business logic to the data model **declaratively** — as metadata — instead of scattering it through application code. It is a cross-protocol capability: automations are declared in the Automation Protocol namespace and executed by the ObjectStack runtime against ObjectQL data.

The smallest useful automation is a hook (from the CRM example app):
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/jobs.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Scheduled Jobs
description: Run a TypeScript function on a cron, interval, or one-off schedule — and decide when a job is the right tool instead of a schedule-triggered flow.
---

# Scheduled Jobs

A **job** runs one named function in your bundle on a schedule. You declare the
schedule as metadata; the platform's job service owns the timing, the retries,
the per-attempt time limit, and the run history.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/webhooks.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Webhook Delivery
description: How ObjectStack reliably ships outbound HTTP notifications — from event to receiver — with at-least-once guarantees, signed payloads, and observable retries.
---

# Webhook Delivery

> **Status:** Shipped · **Audience:** Plugin authors, runtime engineers,
> integration partners
>
Expand Down
2 changes: 0 additions & 2 deletions content/docs/automation/workflows.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Workflow Metadata
description: Use Flow for automation and state machines for strict lifecycle transitions.
---

# Workflow Metadata

ObjectStack no longer has a standalone Salesforce-style Workflow Rule authoring
type. Use:

Expand Down
2 changes: 1 addition & 1 deletion content/docs/concepts/architecture.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,7 +5,7 @@ description: How the Data, System, and UI protocols work together as one cohesiv

import { Database, Layout, Cpu, ArrowRight, CheckCircle, Workflow, Bot, Cloud } from 'lucide-react';

# The Protocol Stack
## The Protocol Stack

The architecture is built on foundational protocols that work together as a unified system:

Expand Down
2 changes: 0 additions & 2 deletions content/docs/concepts/design-principles.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,8 +5,6 @@ description: The unshakable core principles that govern ObjectStack as an AI-nat

import { Scale, Code2, Database, ScrollText } from 'lucide-react';

# Design Principles

ObjectStack exists to make enterprise application development explicit enough for both humans and AI agents to operate safely: **structured business metadata**.

To maintain a healthy, decoupled, and future-proof ecosystem, we uphold the following core principles. These are not suggestions; they are the constraints that enable our freedom.
Expand Down
2 changes: 0 additions & 2 deletions content/docs/concepts/index.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,8 +5,6 @@ description: The foundational ideas behind ObjectStack — metadata-driven devel

import { Scale, Code2, Database, ScrollText, Laptop } from 'lucide-react';

# Core Concepts

Before diving into code, understanding these foundational ideas will make everything else click.

## Find Your Path
Expand Down
2 changes: 1 addition & 1 deletion content/docs/concepts/metadata-driven.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,7 +5,7 @@ description: Understanding how structured metadata becomes APIs, UI, workflows,

import { Database, Code, Link, Laptop } from 'lucide-react';

# What is Metadata-Driven Development?
## What is Metadata-Driven Development?

Metadata-driven development is a paradigm shift where **business intent is defined by declarative, analyzable metadata instead of scattered imperative code.**

Expand Down
2 changes: 0 additions & 2 deletions content/docs/concepts/metadata-lifecycle.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Metadata Lifecycle & HMR
description: How metadata flows through Repository → Change Log → Cache → Registry — the canonical event stream that powers Studio HMR, REST writes, and future cloud editing.
---

# Metadata Lifecycle & HMR

This page documents the metadata data path introduced by [ADR-0008](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0008-metadata-repository-and-change-log.md) and refined by [ADR-0005](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0005-metadata-customization-overlay.md). It is the canonical event stream that powers Studio Hot Module Replacement (HMR), REST writes, and future cloud editing.

<Callout type="info">
Expand Down
2 changes: 0 additions & 2 deletions content/docs/concepts/north-star.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: North Star
description: ObjectStack's current product and architecture direction.
---

# North Star

ObjectStack is the metadata-native backend for business software that humans and
AI agents can both operate safely. The platform makes the business system
explicit: data models, views, flows, permissions, actions, AI tools, and runtime
Expand Down
2 changes: 0 additions & 2 deletions content/docs/data-modeling/analytics.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Analytics Datasets
description: The dataset semantic layer (ADR-0021) — define a metric once, bind reports and dashboards to it by name.
---

# Analytics Datasets

> **Related ADR:** [ADR-0021 — Analytics: one semantic `dataset` layer](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0021-analytics-dataset-semantic-layer.md)

A **dataset** is a named, reusable analytical definition — a base object, the
Expand Down
2 changes: 0 additions & 2 deletions content/docs/data-modeling/drivers.mdx
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -3,8 +3,6 @@ title: Database Drivers
description: Configuration reference for supported database drivers
---

# Database Drivers

ObjectStack supports multiple database backends through a unified driver interface.
Drivers can be selected in two ways:

Expand Down
Loading
Loading