Register a table. It's secured, audited, and queryable.
The schema is the configuration. A governed GraphQL and REST surface exists for every registered table with zero per-table code, over the SQL Server you already run.
- ·Register a table and it comes back secured, audited, and queryable over GraphQL, with no code written per table.
- ·It runs over the SQL Server you already have. No proprietary data store, so there is nothing to re platform to adopt it and nothing to unwind to leave it.
- ·The database keeps the constraints that must always be true. The rule layer above it handles what is true for this tenant this month.
Every new app rebuilds the same data plumbing.
Auth, an API tier, audit columns, CRUD endpoints, paging, filtering. Teams spend months on plumbing before the first business feature ships, and every app does it slightly differently, which is where the security bugs live.
The instant-API tools that solve this are mostly PostgreSQL-first, hosted-only, and make you hand-write row-level security. The enterprise platforms with strong security make you leave your own database and live in their cloud. The combination of your database, your deployment, and automatic security has been the gap.
The mechanisms, not the adjectives.
No ORM, one async data path
All access flows through a single manager over thin, fully-async ADO.NET. No entity classes to generate, no ORM overhead between the app and the database, no second path that skips the rules.
The performance and transparency of hand-tuned SQL, with the uniform enforcement an ORM can't give you.
Metadata-driven API
One set of GraphQL resolvers exposes read, list, paged, write, and delete for every registered table using a dynamic record type. REST endpoints handle sessions and platform services. Register a table, refresh, and it's queryable, permission-checked, and tenant-scoped.
The API scales with the schema, not with engineering headcount. No per-entity endpoint backlog.
Your database stays yours
Forge runs over your existing SQL Server schema. No proprietary data store, no export into someone's cloud, no lock-in of the data model. The metadata engine reads standard relational catalog metadata; PostgreSQL and Oracle support on the same architecture is on the roadmap.
Adopting the platform doesn't mean re-platforming the data. Leaving it wouldn't either.
Validation above, constraints below
Schema constraints stay in the database where they belong. Business validation runs as governed, sandboxed rules above them, live in editors as users type and as an enforced gate on save.
The database enforces what must always be true. The rule layer handles what's true for this tenant, this month.
New table to governed API, in minutes.
- 1
Create the table with a normal foreign key toward your tenant root. Nothing exotic.
- 2
Register it in the security metadata with its permission keys.
- 3
Refresh the dictionary. The engine resolves its tenant path and the API picks it up.
- 4
Query it over GraphQL with paging and filters. Writes carry audit columns and history automatically.
- 5
Grant access to exactly the roles that need it. Everyone else was never able to see it.
The AI angle.
AI-ready data is mostly a governance statement: the analysts predicting 60 percent project abandonment tie it directly to data readiness. A schema that carries its own security, audit, and machine-readable metadata is what ready actually looks like. That's also exactly what the MCP server exposes to AI clients.
Keep going.
Security & multi-tenancy
Tenant isolation derived from foreign keys and enforced in one data path. No filter to forget.
Go deeper →AI done right
MCP-native access, prompt-authored rules, and a security engine every AI agent inherits.
Go deeper →Reporting
Business users build reports; a read-only mirror keeps production safe by construction.
Go deeper →See it on your schema, not ours.
A fixed-price assessment gets this running over your actual data.