I have spent enough time building dashboards to know how satisfying the first one can be. A recurring spreadsheet becomes a clean report. Everyone agrees on a few definitions. Monday morning starts without somebody copying numbers between tabs.
Then somebody asks a good follow-up question.
The operations lead wants to isolate one facility. A sales manager wants to understand why two territories moved in opposite directions. A technician remembers a repair that looks relevant, but the note lives in another system. The dashboard did its job; the question simply moved beyond the view that had been designed in advance.
That moment matters because it shows where many analytics projects stall. The company has useful data and people who understand the work. What it lacks is a practical way for those people to investigate together. Each new question becomes a ticket, a spreadsheet detour, or another request to the person who knows how the warehouse is organized.
I originally wrote about this as an intelligence fabric: a layer that lets people reason across the data a company already has. Since then, the idea has become more concrete for us. It informs how Fulton Ring builds Arcana and, just as importantly, how we introduce it inside a working company.
A dashboard answers the question it was given
A well-made dashboard is valuable. It gives a team a shared view of measures that deserve regular attention. If the same question appears every morning, encoding it once is usually better than asking an analyst to rebuild the answer.
The limitation appears when the work becomes exploratory. Dashboards contain choices about dimensions, filters, time periods, and definitions. Those choices are necessary. They are also boundaries. A question outside them requires somebody to find the underlying records, understand the schema, and decide which comparison is valid.
Large companies can staff that handoff. A smaller manufacturer, distributor, or services firm may have one person who understands the data model and another who understands the operation. Both already have full-time jobs. The delay is often caused by the distance between those two people rather than by a shortage of software.
This is why “more dashboards” is rarely a complete strategy. The reporting layer can be polished while the company still struggles to answer an ordinary question that crosses a work order, a procedure, and a table in the warehouse.
Put the question closer to the person who understands it
The person with the best question is often not an analyst. It may be a maintenance supervisor who recognizes an unusual failure pattern, a planner who knows why a location is hard to serve, or an administrator who can tell when a policy has been applied incorrectly.
Their judgment is the scarce part. SQL is necessary plumbing, but knowing what to ask and whether the result makes sense comes from experience with the operation.
An intelligence fabric should shorten the path between that experience and the evidence. A user ought to be able to ask a question in familiar language, inspect the records behind the answer, and continue the investigation without filing a new request each time. The system needs to preserve definitions and permissions while it does this. Otherwise it merely makes confusion arrive faster.
The idea sounds abstract until you see it in a specific interface. SpiderNet explored it with New York City zoning. The city’s ZoLa application is a powerful source for parcel and zoning information. SpiderNet tested a different interaction: ask a question about a site, work against known public schemas, and return to the official material when the answer needs verification.
The lesson was not that every map needs a chatbot. It was that a domain expert can move further when the interface supports inquiry instead of requiring them to know the application’s internal organization first.
Evidence has to travel with the answer
Natural-language access is useful only when the answer remains reviewable. Operational work contains exceptions, stale records, and competing sources. A confident paragraph cannot resolve those issues by itself.
For an internal system, citations are part of the interface. A supervisor should be able to open the procedure passage, database record, or document that supports a claim. When sources disagree, the disagreement belongs in the result. When the available material does not answer the question, the system should say so.
That makes the tool useful to people who already know the subject. They can challenge an answer without reverse-engineering how it was produced. It also gives the implementation team something concrete to improve. A bad citation, a missing source, or an incorrect definition can be traced and repaired.
Permissions require the same care. Connecting a source does not make every record appropriate for every user. The system needs to inherit the access rules around the material and keep those boundaries visible as information moves into a brief, a message, or an approved action.
Where Arcana fits
Arcana is Fulton Ring’s current implementation of this idea. It connects to the documents and data needed for a defined piece of work, answers questions with sources attached, and can deliver the result through the channels a team already uses. A deployment may involve a document library, a data warehouse, uploaded files, or a combination of them.
The important part is the implementation around the software. We begin with a question that already costs the team time or attention. We identify the sources an experienced person would consult and the reviewer who can judge a useful answer. Then we configure Arcana against that evidence and test it with real examples.
This approach keeps the first deployment narrow enough to evaluate. It also exposes the unglamorous work that determines whether the system lasts: access, source ownership, definitions, failure review, and maintenance when the underlying process changes.
Once the first question works, the same foundation can support adjacent work. A sourced answer can become a recurring brief. A monitored condition can surface an exception. An approved next step can be prepared for a person to review. Expansion follows evidence from use rather than a speculative platform map.
The analyst’s work becomes more valuable
Giving domain experts a direct way to investigate does not eliminate analytical work. It changes where that effort goes.
Analysts spend less time rebuilding familiar extracts and more time defining measures, testing explanations, and improving the evidence available to the company. They can design experiments with operators instead of serving as the queue between a question and a database. When the system produces a weak answer, the analyst has a record of the query, sources, and reviewer response to work from.
That collaboration is especially important as automated tools become capable of writing queries and assembling reports. Generating code is not the same as choosing a valid comparison. The company still needs people who understand sampling, causality, data quality, and the history behind a metric. Automation should give those people more room to exercise that judgment.
What changes for a smaller company
Smaller companies have plenty of operational knowledge. It is usually distributed across software, documents, and a few experienced employees. They also have less capacity to run a long internal platform program.
For them, the practical promise of an intelligence fabric is not universal access to every byte the company owns. It is a shorter path to a reliable answer for work that matters now. The first useful version should arrive with clear boundaries and somebody accountable for keeping it working.
That is why Fulton Ring treats Arcana as a delivered capability. We set up the connections, work through the initial questions with the people who know the operation, and stay involved after launch. The client should gain leverage from its own knowledge without having to become an AI integrator along the way.
Dashboards will remain part of the picture. Some questions deserve a stable chart. Others begin with a hunch, cross several sources, and change as the evidence appears. The intelligence fabric is for that second kind of work: the investigation the company already knows it needs to conduct, finally brought within reach of the person equipped to lead it.
Sources
- Rajan Desai, “The Intelligence Fabric: Why Dashboards Aren’t Enough, and the Future of AI-Enabled Analytics”, originally published February 19, 2026.
- SpiderNet, the public zoning-interface experiment discussed above.
- NYC Planning ZoLa, the official zoning and land-use application SpiderNet builds upon.