ACORE ECOSYSTEM
Live demoAcore
One typed application model
Acore UI · native API · PostgreSQL13 authored files898 lines incl. tests
Visit website ↗[ SAME PRODUCT. A DIFFERENT FOUNDATION. ]ONE BOARD.
ONE BOARD.
THREE STACKS.
ONE BIGGER IDEA.
The same Kanban experience, built three ways. Explore what changes when UI, API, data and policy become one connected model for humans and agents.
Real applicationsIndependent databasesSame core workflows
orbit / application.acoreTYPED + CONNECTED
// One language. Connected layers.
model Task {
title: String
dependencies: List<String>
}
page Home {
query tasks = Board.list_tasks(...)
view { TaskBoard(tasks: tasks.data) }
}APPLICATION MODEL ↗
UIAPIDATA
WEBANDROIDiOS
↳ Trace a field. Inspect its consumers. Review its impact.
TYPED CONTRACTSSEMANTIC CONTEXTSANDBOXED EXTENSIONSRUNTIME POLICIESNATIVE TARGETS
01 / TRY THE SAME APPSame board.
Same board.
Open all three.
Create a task. Add a prerequisite. Move it through the board. Search, filter and edit. Each demo runs its own implementation and persists to its own database.
SAME APP / FLUTTER
Live demoFlutter + Serverpod
A shared Dart codebase
Flutter UI · Serverpod · PostgreSQL18 authored files2,281 lines incl. tests
Visit website ↗SAME APP / NEXTJS
Live demoNext.js
A full-stack web application
React · Next.js API · PostgreSQL12 authored files706 lines incl. tests
Visit website ↗Public sandbox boards are shared between visitors. Use sample data. The embedded previews are interactive; open a full website for the complete viewport. Native targets are compiler-checked in this example; browser responsiveness is not a device test.
02 / WHY A CONNECTED MODEL MATTERSThe app is the demo.
The app is the demo.
The foundation is the advantage.
AxiomCore brings application structure, runtime behavior and reviewable evidence into the same workflow. Here is where that can make a difference as teams and codebases grow.
01 / Built for agents
Give the agent the application, not a pile of files.
One connected model
UI, API, data, validation and policy share a typed vocabulary. An agent can follow a feature across its declared boundaries.
Retrieve just the relevant nodes
Compiler-derived IDs, typed relationships and bounded projections make focused context retrieval possible without loading the entire codebase.
Understand a change before making it
Trace affected endpoints, projections, UI consumers and targets through recorded dependency paths. Coverage and unknowns stay explicit.
Compiler-owned semantic edits
Studio tools discover legal edits, update supported nodes and compile candidates. Broader backend and schema edit families are on the roadmap.
Less repeated wiring
Typed contracts and generated clients carry data shapes across boundaries, reducing the integration code an author has to maintain.
A smaller place to start
This Orbit implementation has 13 counted authored files and 898 lines, including tests. Flutter + Serverpod has 18 files and 2,281 lines.
Grounded answers, with evidence
Inspector can explain ownership, reads, writes and permissions using graph facts and evidence references instead of a guessed architecture.
A shared language for the team
Developers and agents inspect the same declarations and diagnostics. Intent stays reviewable in source rather than disappearing into a prompt.
Specialization without lock-in
The semantic tool protocol is designed for existing capable models. A specialized edit model can be evaluated later against the same checks.
Revision-bound context
Source and graph revisions let tools identify stale context and bind a proposed change to the application the agent actually inspected.
Machine-readable developer tools
Structured diagnostics, schema catalogs and JSON inspection outputs let an agent work with compiler facts through repeatable tools.
Reusable typed packages
Pinned package contracts and resolved imports let teams share supported types and interfaces without copying their implementation into every prompt.
02 / Managed by the runtime
Declare the behavior. Let a shared execution layer carry it.
Caching with a contract
Declare cache strategy, lifetime and identity. In Orbit, successful mutations invalidate the shared board cache.
Typed requests and failures
The contract carries input/output types, bounded validation and named failures, giving clients a consistent success and error surface.
Pending, error and refresh state
Queries and mutations connect UI state to the runtime so loading, failure and refresh behavior follow the declared operation.
Authorization at the boundary
Guards, declared effects and resource grants make access requirements visible to the compiler and execution host.
Sandboxed extensions
Supported extension profiles run behind a sandbox and capability broker. Authority comes from explicit grants rather than ambient access.
Controlled effects and I/O
Network, storage and other host operations pass through declared boundaries. An extension cannot gain a capability just by requesting it.
Policy-aware resilience
Timeouts, retries and circuit behavior are declared where supported. Unsafe operations retain explicit replay and idempotency boundaries.
One place to inspect behavior
Declared policies, compiled relationships and observed execution are distinct evidence layers, making audits easier to follow.
Business logic stays explicit
The runtime handles supported cross-cutting behavior; domain algorithms and database invariants remain authored, typed or implemented in supported extensions.
Cancellation and request identity
Supported query lifecycles track request identity and cancellation so superseded work does not silently become current UI state.
Explicit streaming contracts
Supported stream profiles describe event types and delivery policy, keeping streaming behavior visible alongside the operation that produces it.
Selected state persistence
Supported UI state-persistence profiles can retain selected application state. Durable offline writes remain a separate capability.
03 / Ready across platforms
Keep a coherent product as the number of targets grows.
Web, Android and iOS
Acore targets the browser and native Android/iOS hosts from shared UI source. Orbit has compiler checks for all three targets.
HTML on the web
The web host renders DOM content and supports ordinary page metadata. Indexable HTML gives content-oriented sites a path to web SEO.
Three primary source layers
A minimal full-stack app can organize its UI, API and schema into three primary source files, with manifests and host setup around them.
Typed database definitions
Describe supported PostgreSQL and SQLite schemas, constraints and relationships with a typed database authoring profile.
Review database evolution
Schema comparison, migration planning and supported apply/history workflows make database changes reviewable alongside application changes.
Versioned, verifiable contracts
Artifact hashes, signatures and pinned dependency locks connect consumers to an exact reviewed contract version.
Deploy through repeatable artifacts
Compile and package the application for its selected host; keep environment configuration and secrets separate from authored source.
Adopt alongside an existing stack
Extract or consume supported backend contracts and use existing clients incrementally. A full application rewrite is not required.
Tests across the boundary
Contract checks, scenarios, API tests and target checks can verify more than the UI. Orbit passed the same 44 graph checks in each stack.
Responsive, accessible interfaces
Describe responsive rules, input semantics, labels and interaction state in the UI source, then check the selected target.
Reusable component contracts
Supported components carry typed inputs, events and composition boundaries, helping teams build a coherent design system.
Local review and CI evidence
Run semantic comparisons and relevant checks locally, then attach exact revisions, impact and test evidence to a repeatable review workflow.
03 / DECLARE ONCE. EXECUTE CONSISTENTLY.More behavior.
More behavior.
Less repeated work.
From live updates to helpful form feedback, the shared runtime handles common behaviors that every app needs. Teams declare the rules and keep their attention on the product.
These are platform capabilities. The Kanban demo uses a subset; availability varies by host and selected profile.
Live updates without refreshing
Stream new information into a screen as it arrives, on supported hosts.
Helpful form feedback
Check declared field rules and explain what needs fixing before data is accepted.
Errors people can act on
Give the app a consistent way to show what went wrong and what can happen next.
Faster repeat visits
Reuse saved results when the app’s declared policy allows it.
Keep screens up to date
Refresh the relevant saved results after a successful change.
Clear loading and saving states
Let screens show when an action is working, has finished or needs attention.
Recover from temporary failures
Retry eligible requests under the app’s declared rules.
A limit on waiting
Stop requests that exceed their allowed time, so a screen can offer a next step.
Keep the latest search current
Coordinate supported request lifecycles so superseded results do not take over.
Access rules in one place
Check the declared sign-in and permission requirements at the operation boundary.
Safer add-ons
Limit supported sandboxed extensions to the specific capabilities they are granted.
Remember selected app state
Retain selected state where the chosen UI host supports persistence.
Consistent data between screens
Check incoming and outgoing data against the application’s shared contract.
Handle busy periods predictably
Apply supported capacity and queue limits instead of accepting unbounded work.
Follow what happened
Connect operations and failures with execution records that teams can inspect.
04 / THREE PRIMARY SOURCE LAYERSA full-stack starting point.
A full-stack starting point.
Without three languages.
Small apps can keep their schema, API and UI in three primary source files. Typed manifests, tests and deployment configuration sit alongside them as the app grows.
schema.acore
table tasks {
title: Sqlite.Text()
}Describe the data and supported constraints.
application.acore
model Task {
title: String(maxLength: 120)
}
endpoint create_task(...)Declare typed operations, failures and policies.
main.acore
page Home {
query tasks = Board.list_tasks(...)
view { TaskBoard(...) }
}Connect the same contract to web and native UI.
Illustrative excerpts, not a runnable three-file bundle. Orbit includes additional models, persistence code, migrations and tests. Generated files and setup are excluded from the authored-source counts.
05 / HOW AN AGENT FINDS AND CHANGES THINGSAsk for a change.
Ask for a change.
See the path to it.
Every agent needs to find the right part, understand it, make a change and check the result. Acore adds a direct path to supported application nodes.
Illustrative workflows, not a speed or token measurement. Acore Studio semantic UI editing is a preview capability.
ONE REQUEST / THREE WORKFLOWS
UI CHANGE · SAME RESULT“Rename the New task button to Create task.”
SEMANTIC TOOLS / STUDIO PREVIEW
Acore
Retrieve a node. Edit a property.
01 / UNDERSTAND THE REQUEST
Locate the primary action
Find the button that opens the task editor.
Intent → application node
Same intent. A typed application model.
SOURCE + ECOSYSTEM TOOLS
Flutter + Serverpod
Find the widget. Edit the source.
01 / UNDERSTAND THE REQUEST
Locate the primary action
Find the widget that opens the task editor.
Intent → widget source
Same intent. A shared Dart codebase.
SOURCE + ECOSYSTEM TOOLS
Next.js
Find the component. Edit the source.
01 / UNDERSTAND THE REQUEST
Locate the primary action
Find the component that opens the task editor.
Intent → component source
Same intent. A full-stack web codebase.
WHY IT MATTERS
A node carries its identity, properties and relationships. The agent can request the relevant context and propose a supported edit while the compiler checks the candidate. The change stays visible in source for people to review.
Simplified tool calls and source excerpts. Source-based agents can also use language servers and structured tools. This label change needs no database migration or backend change in any stack. Supported scalar UI edits are demonstrated here; broader schema and backend edit families have separate availability.
06 / THREE APPROACHES, SIDE BY SIDECompare the
Compare the
building blocks.
All three demos implement the same product. Compare how each stack organizes UI, data, runtime behavior and tooling. AxiomCore connects those declared relationships in one application model.
| Capability | Acore CONNECTED MODEL | Flutter + Serverpod | Next.js |
|---|---|---|---|
| Application source | Acore across declared layers | Dart UI + Dart server | TypeScript UI + server |
| Web + Android + iOS | Shared UI; native target hosts | Shared Flutter widgets | Web; native needs a separate approach |
| Web presentation | DOM-based web host | App-centric Flutter renderer | HTML, React and server rendering |
| Application impact | Compiler-derived cross-layer evidence | Project tooling and application conventions | Project tooling and application conventions |
| Agent editing | Typed node tools in Studio preview | Source and ecosystem tools | Source and ecosystem tools |
| Caching | Declared policies and invalidation | Serverpod cache + application logic | Framework and application caching |
| Extension authority | Sandbox + explicit capability grants | Application and platform choices | Application and platform choices |
| Release evidence | Pinned, signed contract artifacts | Build and deployment pipeline | Build and deployment pipeline |
ABOUT THE NUMBERS
Source counts use the same retained-authored-code boundary, including tests. Generated code, dependencies, assets and project setup are excluded. File count and line count describe footprint; they do not establish development speed or token savings. Broader semantic editing is a Studio preview/roadmap capability, rather than a claim that this benchmark used every tool.
Read the detailed benchmark and methodology ↗
01 / START BUILDING
Your first connected app ↗Scan to open the docsdocs.axiomcore.dev
Meet your next workspace ↗Scan to join the waitlistaxiomcore.dev/waitlist
BUILD SOMETHING CONNECTEDGive your agents
02 / JOIN THE WAITLISTGive your agents
the full picture.
Build with Acore today. Join the AxiomStudio waitlist for the agent workspace built around your application model.