Documentation

What Aurora Is

Aurora creates a new category: Situational Intelligence Infrastructure. Traditional systems optimise profiles, segments, and historical behaviour. Aurora optimises intent, mission state, urgency, and context. Humans operate in states; Aurora makes digital systems respond to those states in real time.

Aurora is not a no-code builder. Not an AI chatbot. Not a personalisation layer. It is infrastructure that understands the moment. It is the execution layer Holmes needs to feed on clean signals and to change behaviour.

Holmes infers what a user is trying to accomplish right now. Aurora provides the domain model, events, workflows, and operational triggers so that inference can turn into action. Without Aurora, Holmes would have nothing to observe and nothing to control.

Holmes: The Inference Engine

Holmes uses deterministic and heuristic algorithms with configurable business rules. It consumes behavioural events, detects mission states, and outputs confidence scores. It does not use generative AI. It changes system behaviour. Example: a user rushing to buy tickets. Holmes infers urgency from typing speed, referral source, and context, and switches to fast-checkout mode. No asking. It notices.

Holmes is the strategic core. It answers: What is this human trying to accomplish right now? How urgent? What should the system optimise for? Has the mission shifted mid-session? Chatbots help users navigate systems. Holmes makes systems adaptive.

Holmes integrates via a small script on your storefront or site. It captures signals (navigation, search, typing, cart), sends them to Aurora, and receives inferred intent and suggested actions. Your front-end presents them: bundles, express checkout, simplified flows.

Holmes directives - real-time UX

Holmes emits directives that manipulate the DOM in real time. Mark regions with data-holmes attributes:

• data-holmes="checkout-extras" - hidden when enable_fast_checkout
• data-holmes="cross-sell" - hidden when suppress_cross_sell
• data-holmes="recommendations" - hidden/shown by reduce_recommendations / expand_discovery
• data-holmes="payment" - highlighted when payment_pre_focus
• data-holmes="basket-bundle" - bundle suggestion in cart

Use getHolmesScriptUrl() from @aurora-studio/sdk to load the script. See the Aurora Studio repo docs for the full directive reference.

Holmes Store API: combos, recipes & intent alignment

When Holmes is enabled for commerce, the SDK exposes storefront methods for combos (canonical), recipes (ecom alias), contextual hints, cart bundles, and mission-aware home content (SDK 0.2.22+ for cart combos and hasCombo hints):

• store.holmesCombo(slug) / store.holmesRecipe(slug): Cached combo or recipe from catalog or pre-seeded content
• store.holmesTidbits(entity, entityType) - Tidbits for recipes, ingredients, products
• store.holmesContextualHint(params) - "Paying attention" hint; optional cartIds for bundle fingerprinting; may return hasCombo, comboTitle
• store.holmesCombosForCart({ cartIds, cartNames?, limit? }) - One to several bundle options for the cart (2+ line items)
• store.holmesSelectCombo({ sid, slug, title? }) - Persist shopper’s chosen combo on the Holmes session
• store.categorySuggestions(sid) - Holmes-driven category order
• store.holmesComboProducts(combo) / store.holmesRecipeProducts(recipe) - Products for a combo or recipe
• store.holmesGoesWith(productId) - Products that go well with a given product
• store.holmesRecentCombos() / store.holmesRecentRecipes() - Recent combos for discovery
• store.homePersonalization(sid) - Hero + sections; when recipe mission: mode: "recipe_mission", recipeSlug, quickActions, missions, shoppingListTemplates. Returns activeMission (key, label, confidence, band, summary, uiHints) when inference ≥ 0.6. Use for mission bar, catalogue narrowing.

Intent alignment: mission-driven UX by default when confidence is high (active mission bar, mission-first surface, narrowing). Roadmap: dismissing mission chrome should fall back to signal-priority Holmes (prioritised categories, hints, bundles, directives) without turning inference off. See holmes-next-steps-mission-mode.md in the Studio repo.

Aurora: The Backbone Holmes Needs

Aurora exists to feed Holmes clean signals and to enable behavioural authority. It provides:

• Structured domain modelling, data that Holmes can interpret
• Event-native architecture, state changes become observable events
• Workflow branching, execution paths that can adapt
• Operational triggers, workflows and automation that respond to events
• Secure multi-tenant foundation, enterprise-ready isolation

The builder (sections, forms, views) is the enabler. Holmes is the brain. Aurora is the infrastructure. You can start fresh with Holmes-native templates (born intelligent) or integrate Holmes into existing systems via event adapters and behaviour hooks. Aurora is optional for integration but optimised for Holmes.

Data Builder & Sections

Sections are your domain model: tables, fields, relationships. This structured data gives Holmes something to interpret. Define fields, validation rules, and computed fields. Bulk import from CSV or Excel.

Views join tables for read-only grids. Create cross-table views (e.g. orders with customer names), then embed them in forms. Custom forms combine form fields, related tables, and embedded views with inline layout editing. Edit layout to drag, resize, and connect sections. AI-assisted creation for both forms and views.

Domain events flow from state transitions in your data. Order paid, inventory low, record updated. These events feed Holmes and trigger workflows. The data layer is the source of truth for what Holmes observes and acts on.

Workflows & Domain Events

Domain events turn state changes into durable, observable signals. Workflows react: send email, create records, call APIs, run scripts. Triggers fire on record events, domain events (order.paid, inventory.low), or webhooks.

This event-native architecture is what makes Holmes possible. Holmes infers; Aurora executes. When Holmes detects a mission shift, the system can adapt ranking, checkout flow, or operational logic because Aurora provides the execution layer.

Reports & Observability

Build reports with a query builder: joins, filters, grouping, aggregates. Dashboards show metrics and charts. Holmes must be measurable: inferred mission distribution, confidence scoring, state transitions, outcome deltas.

The control plane lets operators see what Holmes is detecting and how the system is adapting. Situational intelligence only works if you can observe it.

Search

Full-text search across your data. Search behaviour is a strong signal for Holmes. What users type and what they find feeds into mission inference. Configure indexes and expose search via your store or API.

Workspaces & Security

Multi-tenant workspaces with roles: Owner, Admin, Member, Read-only. Data isolation, authentication, and audit logging. Aurora is built for production. The backbone must be secure.

Holmes operates within this secure foundation. Signals, inference, and execution all respect tenant boundaries.

Holmes-Native Templates & Deployment

Templates are not "store builders." They are reference implementations that demonstrate mission-aware behaviour. They are launch-ready adaptive systems. Start with a template and you get structured data, event-native backbone, real-time inference, and adaptive execution from day one. Born intelligent.

Expose your data via RESTful API. Use SDK and app templates for custom front-ends. Deploy to popular hosting platforms. Aurora is hosted by default, so there is no infrastructure to manage.

Or integrate Holmes into existing commerce, government, travel, or enterprise systems. Event adapters and behaviour hooks let Holmes plug in. Aurora is optional for integration but optimised for it.