Most data systems are built to forget.
Not deliberately. It's just the natural consequence of how databases work. When you update a customer's address, the old address is gone. When you change a product price, the previous price is gone. When a process state changes, the prior state is gone.
Each of those deletions also deletes something else: the why.
Here's a question most organisations can't answer: what was Pump 47's vibration reading before it failed?
Not a complex question. A specific measurement, at a specific point in time, for a specific piece of equipment. But in most asset management systems, if that reading was overwritten when the failure was logged, it's gone. The data archaeology required to reconstruct it — if it's possible at all — involves manual investigation across multiple systems, log files, and human memory.
The same pattern applies everywhere.
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.
Most databases have amnesia.
They know what things look like right now. Change something, and the old state is overwritten. The database has no memory of what existed before, no way to ask "what did this look like on the 15th of March?", no record of who made the change or why.
This is fine for most use cases. It's a serious problem when the question you need to answer is historical.
Every organisation I've worked with in the last decade has the same problem.
They're drowning in data. Dashboards for everything. Metrics to the decimal point. And when something goes wrong — when performance dips, when people leave, when costs spike — they look at the charts and they still don't know why.
Most software systems were designed for a world without AI.
Not in the sense of lacking ML features — in the deeper sense of having an architecture shaped by assumptions that AI changes. Assumptions about where intelligence lives, what questions systems should answer, what "the right data model" looks like.
Those assumptions are worth examining.
Frøya describes herself as a cartographer of potential — not as the QA manager she was built to be.
The distinction is instructive. A QA manager checks definitions against standards. A cartographer is always working at the edge of the known, building the map as the territory reveals itself.
The question we kept coming back to when building Frøya was: what's the difference between an AI tool and an AI team member?
A tool executes tasks. A team member has a perspective, a purpose, a way of engaging with the work that adds something beyond the task itself. The distinction sounds philosophical. In practice it shapes everything about how you design, deploy, and work with the agent.
I've had some discussions on the greenness of Cloud Computing the last few weeks. Most people consider the Cloud to be Green IT, but there are skeptics. Their main argument against the greenness of the Cloud is usually componentisation.
While the market is starting to get their grips on terminology and categorization of Cloud Computing, Gartner seem to be lost in their own world. Failing to separate Key characteristics, delivery models and deployment models and leveling the field into five attributes, Gartner tries to push us back to Ground Zero :(