From Data to Action: The Alchemy and Aurora Stack¶
The hardest part of analytics isn't the analysis. It's getting the data there in the first place.
Most organisations have data in a dozen places. ERP systems. HR platforms. CRM. Custom databases. Real-time event streams. Legacy systems that predate modern API design. Getting all of that into a consistent, queryable format is the project that takes eighteen months and still isn't finished.
Xorcery AAA is built around two components that solve this problem together.
Alchemy: the data connection layer¶
Alchemy is the ingestion engine. Its job is to connect to any data source — live streams, stored datasets, industry-specific systems — and transform that data into event streams that Aurora can consume.
The design philosophy matters here. Alchemy is configured, not coded. YAML and JSON configuration files define the pipelines: what sources to connect, how to transform the data, where to send it. This means a domain expert who understands the data structure can define the pipeline without requiring a software project. It also means the pipelines are readable, reviewable, and maintainable in ways that custom integration code often isn't.
The pipelines are reactive — built for real-time processing, not batch jobs. When something changes upstream, the event flows through immediately. The analytics downstream reflect the current state, not the state from the last overnight run.
This is the part of temporal analytics that's easy to underestimate. The temporal graph is only as useful as the data that feeds it. If ingestion is slow, fragile, or expensive to maintain, the whole system degrades. Alchemy is engineered specifically to be none of those things.
Aurora: the temporal event store¶
Where Alchemy handles connection and transformation, Aurora handles storage and querying.
Aurora is a temporal graph database built on Neo4j. Events flow in from Alchemy and are stored with full temporal metadata — not just what happened, but when it was valid, when it was recorded, and what the organisational context was at that moment. Relationships between entities are stored as first-class graph connections, not foreign keys in join tables.
The query interface is GraphQL, with temporal extensions that let you specify exactly which point in time you're querying from. Ask for the organisational structure as it was on any date. Get back the state that actually existed then — not the current state with historical notes appended, but the actual bitemporal snapshot.
Add the AI layer and those queries become conversational. Instead of writing Cypher, you ask in plain English. The AI translates intent into query, runs it against the temporal graph, and returns a clear answer — along with the reasoning that produced it.
Why the two-layer design matters¶
The obvious question is: why two systems? Why not a single platform that does everything?
The answer is about separation of concerns. Alchemy's problem is connectivity and transformation — it needs to be flexible, configurable, and capable of handling the heterogeneous mess of real enterprise data sources. Aurora's problem is storage and reasoning — it needs to be precise, performant, and capable of complex temporal graph traversal.
Combining both responsibilities into a single system would force compromises in both directions. Keeping them modular means each can be optimised for its actual job, and each can be integrated independently where appropriate.
It also means the architecture scales cleanly. Add new data sources to Alchemy without touching Aurora. Scale the query layer independently of the ingestion layer. Replace components as better technology emerges without rebuilding the whole system.
The path from data to action¶
What the two-layer stack produces, end to end, is a closed loop:
Data exists in source systems, constantly changing. Alchemy connects to those systems and streams changes into Aurora as temporal events. Aurora stores them with full graph context and temporal precision. The AI layer makes that store queryable in plain language. The answers that come back are the why questions that standard reporting can't answer.
And those answers drive action. Not after weeks of analysis. Not after manual reconstruction across multiple systems. In seconds, from a question asked in the same language as the business problem.
That's the full chain. Data to action.
Part of the Xorcery AAA product suite — temporal analytics and AI intelligence infrastructure built by eXOReaction.
This post is part of the AI-Augmented Development series.
Series: Aurora & Temporal Analytics
← Unlocking Temporal Graphs · Part 4 of 5 · The Organisational Amnesia Problem →