White Paper

Foreword

Over twenty years, the companies that chose to transform digitally have moved through three waves. The first was the digitalization of processes: from paper to PDF, from fax to email. The second was operational efficiency: ERP, CRM, automations, dashboards. The third, underway since late 2022, is the wave of generative artificial intelligence: bots, copilots, agents. All three treated the company as a set of processes to accelerate. The most important part, the way the people who lead the company think, stayed outside their reach.

UBcore was born for the fourth wave, the one the first three prepared without knowing it: the cognitive transformation of the decision-maker. A cognitive exoskeleton that works alongside the people who make decisions, not in their place, trained on the company's DNA, independent of the large vendors, under the customer's full control.

The document you are reading is a snapshot, in plain language, of what UBcore is today, of the choices that have defined its shape, and of where the project is heading. It is meant for those who, before a meeting, want to know who they are about to face. For those who have no time to sit through a demo without first having understood whether the promise holds.

The document is structured in seven sections. The first shows UBcore in action. The second frames the blind spot of the AI market in 2026. The third explains the shift in register, from AI as oracle to AI as thought partner, that changes the product category. The fourth describes UBcore in detail. The fifth recounts how it was built. The sixth states guarantees and active work in progress. The seventh closes with the posture and the invitation.

It reads in thirty minutes. It is designed for that.

1. A day with UBcore

UBcore lives in the browser, and opens the way email opens. The interface is a natural-language conversation with a system that knows the company of the person speaking.

In these pages the term "decision-maker" is used in a broad sense: anyone who makes decisions in a company, at any level: from the general manager assessing an acquisition, to the legal officer checking the compliance of a document, to the technical lead choosing a supplier, to the employee applying a complex procedure. UBcore works for anyone, in a company, who has to bring a choice to a system that helps them build it.

The decision-maker brings a request to the system, and gets what they need: information retrieved from the company's assets, a summary before a meeting, or, in the moments that matter, the structured articulation of a strategic choice.

Four examples, taken from what an average day involves.

Quick retrieval. The administrative director looks for the current version of an internal procedure, and wants to know whether it is consistent with the contract signed with a supplier three months ago. "Retrieve procedure X for me, check the latest version of the contract with [supplier], tell me where the two things touch." UBcore goes and fetches the procedure from the document repository, retrieves the contract from the system where it lives, and highlights the points of contact and the discrepancies. Three minutes.

A summary before a meeting. The CFO has a board meeting in an hour about last quarter's performance. "Put together for me the last three conversations we had on the Q4 results, the closing figures that came from management control yesterday, and the strategic posture we should bring into the board." UBcore consults the previous conversations, retrieves the operational data, recalls the decision criteria that the decision-maker has codified over the years. It returns an ordered picture that the CFO can add to the slides or keep as an internal reminder.

A strategic acquisition. The CEO of an industrial services company is assessing the acquisition of a smaller firm with drone technology. "We are assessing the acquisition of [target]. Retrieve what we discussed in the last three conversations on M&A strategy, check the target's latest financial statement that arrived by email last week, and tell me whether the move is consistent with our strategic constitution." UBcore does not ask the CEO to attach anything. It retrieves the financial statement from the inbox, the conversations from memory, the decision criteria from the company's constitution. It returns where the acquisition is consistent with the existing strategic posture, where it creates tension, where the CEO's decision must compensate for a discrepancy.

Market positioning. The marketing manager is preparing the quarter's plan and has a doubt that no dashboard resolves: does the way the company tells its own story still hold? "Reread our positioning document, compare it with the results of the last two campaigns and with the market research that arrived last week, and tell me where the story we tell about ourselves and the numbers do not match." UBcore retrieves the declared positioning, the buyer personas codified in the company's constitution, the campaign data, and highlights the gaps: where the market perceives something different from what the company declares itself to be.

Four interactions, four registers. In the first two, UBcore works on the operational plane: retrieval, summary, cross-checking. It is the daily backbone, where the decision-maker builds trust in the tool. In the other two, UBcore works above the operational line, where strategic choices take shape. Same tool, same language, same memory accumulated in the previous interactions.

The distinctiveness is here. Not in the horizontal work taken on its own: good document assistants exist. Not in the strategic moments taken on their own: dedicated decision intelligence frameworks exist. The distinctiveness is in the fact that the same system does both, because it has the same identity as the customer, the same strategic constitution, the same evaluation criteria. The decision-maker does not change tool, context, or language when moving from the morning question to the afternoon choice.

The sections that follow frame why this configuration is rare today in the AI market for structured companies, and how UBcore is designed to sustain it.

2. The market's blind spot

The companies that introduced generative artificial intelligence tools into their processes over the last two years now face a recurring fact: the AI pilot that looked promising at six months is no longer used at twelve months, or is used for something very different from what it was designed for. The phenomenon is broad enough that it cannot be treated as a bump in the road. The market now openly calls it the AI purgatory: the state of permanent stalemate between experiment and production.

The numbers converge. McKinsey, in the report The State of AI in 2025 (November 2025), finds that only 39% of organizations report a measurable impact on enterprise-level EBIT from the use of AI, and that only 6%, the AI high performers, attribute to it an impact above 5%. For the remaining 94%, AI has not yet moved the margin in any significant way. BCG, in the report The Widening AI Value Gap of the same year, documents that 60% of companies generate no material value from AI investments, and that only 5% reach substantial value at scale. Gartner, in an analysis published in January 2026, finds that at least 50% of generative AI projects were abandoned after the proof-of-concept phase by the end of 2025. The three sources, from different angles, capture the same landscape: the majority of enterprise AI projects do not reach production, or reach it without generating the expected value.

While this landscape was consolidating, the category that runs through it received an official map. On 26 January 2026, Gartner published the first Magic Quadrant for Decision Intelligence Platforms, with seventeen vendors evaluated: decision intelligence formally recognized as a category for the first time. The use cases that Gartner associates with the category, from credit approval to fraud detection, from supply chain planning to price optimization, place it today in operational and transactional decisioning. UBcore works in an adjacent space, where decisions are not operational but interpretive and at the top: above the operational line. The map, today, exists. The region in which UBcore operates is at its edges, and remains largely still to be inhabited.

The cause is not technological

The interesting part of the phenomenon is where the sources locate the cause. The converging studies place it outside the technological plane: the model understands, the infrastructure holds, the tools work. The primary cause lies elsewhere: adoption complexity, unmanaged expectations, lack of internal skills, data governance that is not ready. BCG puts it plainly: AI does not lack capability; it is organizations that lack the structure to absorb it.

Translated into plain language: the problem is not the tool. It is the way the tool meets the organization that should use it. And that way is made, in most cases, of choices that precede AI (of process, of culture, of governance) that the introduction of AI makes visible, but that AI alone cannot resolve.

The blind spot: AI as oracle

There is a second level, beneath the one documented by the sources. It is harder to measure, but easier to observe in companies where the AI pilots have taken root.

When an organization introduces an AI tool, it uses it in the way it learned to use the tools it already had. It uses it as an oracle: you ask a question, you receive an answer, you take it as given. Or as a convenience assistant: you delegate a task you could do but that would take time. These are legitimate uses, and they produce value. But they leave most of the tool's power on the table.

A latest-generation model (Claude, GPT, Gemini) is not a jukebox of pre-packaged answers. It was built to reason. To reason, from the point of view of the person using it, is something different from answering: it means bringing the tool a choice to build, not a question to give voice to. It means accepting that the tool, where appropriate, answers with further questions: asks to clarify an assumption, to name the main constraint, to make explicit a decision criterion that had not been declared.

This shift, from AI as oracle to AI as thought partner, the market has not yet internalized. It is the blind spot that explains why the most powerful tools are used today at a fraction of their capabilities.

The cognitive framework that enables the shift is the subject of section 3. First, however, one last survey of the landscape is needed: where UBcore lives, relative to the other AI products for structured companies on the market.

The layering of the corporate world

The technology stack of companies of a certain complexity is organized today into three vertical layers. None of the three is redundant. Each has its own function.

Layer 1 is the plane of transactional systems. ERP, CRM, data warehouse, document systems, ticketing. A consolidated market (SAP, Microsoft Dynamics, Salesforce, HubSpot, Zucchetti): the company's operational data lives here. The technology is mature, the investments are amortized, the consulting ecosystems that revolve around it are deep.

Layer 2 is the plane of agentic automations and operational orchestration. Advanced RPA, advanced RAG, agents that perform repetitive tasks, process copilots that integrate the systems with one another. It is the ground that AI boutiques and advanced system integrators have built over the years: their craft, made of integrations, proprietary connectors, knowledge of the customer's specific domain. When the head of a department says "I would like the system to automatically prepare the offer, check warehouse availability and send the confirmation to the customer", they are talking about Layer 2.

Layer 3 is the plane of the cognitive layer of the decision-maker. There strategic choices take shape. There the general manager articulates an acquisition, the finance director builds a positioning analysis, the founder assesses a repositioning. But also, on a different scale: the legal officer assessing the compliance of a procedure, the technical lead choosing a component, the commercial manager articulating a complex negotiation. Layer 3 activates whenever a decision requires articulated reasoning, not just the retrieval of information. This layer, above the transactional systems and above the operational automations, is largely still empty. The AI products for structured companies available today man Layer 1 (BI, document automation) or Layer 2 (operational copilots, process agents). Layer 3, AI as the decision-maker's thought partner, is inhabited by a few laboratories that have deliberately chosen to build there.

UBcore is one of those laboratories. When a company already has its own Layer 2 in the hands of a partner (an AI boutique or an advanced system integrator), UBcore sits above the partner's automations, and the output of those automations becomes one of the sources of intelligence that feed the cognitive layer. In leaner contexts, typical of mid-market SMEs, UBcore works directly above the customer's transactional systems, through an open standard called Model Context Protocol (described in section 4). In both cases, UBcore integrates into a higher cognitive layer: it lives above, there where the decision-maker makes the decisions that the other two layers execute.

The next section describes the cognitive framework that Layer 3 requires, the shift from AI as oracle to AI as thought partner, and why this shift changes the product category.

3. The cognitive framework

The previous section described the blind spot: AI is a reasoning tool that the market is still using as an answering tool. This section explains what, in practice, the jump from one to the other means, and why that jump changes the product category, not just the user's experience.

By cognitive framework, in these pages, we mean something precise: the way the person using an AI tool questions it, structures it, puts it to work. Not the model itself, that is given. Not the interface, that is the same for everyone. The cognitive framework is the practice with which the decision-maker formulates their requests, decides when to stop, recognizes when the tool is working well and when it is not. It is the discipline of the user, codified.

AI as oracle, AI as assistant

When a person opens an AI copilot for the first time, they use it in the ways they already knew. They use it as an oracle: they ask a question ("what is the best way to do X?"), receive an answer, take it as given. Or they use it as an assistant: they delegate a task they could do but that takes time ("write this email", "summarize these documents", "generate ten variants of this headline") and earn back an hour of work.

These are legitimate uses. They generate value. For many activities, that is exactly what is needed. But if you stop here, you are using a tenth of the tool's power.

Why the market does not see it yet

When a tool is radically new, people tend to use it in the ways they already know. It happened with the computer: the first people to have one on their desk used it as a better typewriter. It happened with the internet: the first websites were HTML brochures, static translations of paper leaflets. It happened with the smartphone: in the first two years, the majority of users treated it as "a phone that also does email". The cognitive leap always comes later. Often years later.

With generative artificial intelligence the same thing is happening. The majority of people, and of organizations, are still using AI as a very sophisticated version of the search engines or text editors they already knew. A third paradigm is missing, and it is the only one in which the model's power is actually put to use: AI as a thought partner.

AI as thought partner

A thought partner does not answer questions. It puts them under tension.

When you bring a choice to a thought partner, you do not receive the answer. You receive another question: "from where did you see this choice? Which assumption are you taking for granted? What would change if the main constraint were Y instead of X?". You receive an angle that had not been considered. You receive the note that the same question, formulated three months ago, would have been posed differently, and that it is worth asking why.

A thought partner forces you to think better. It is the opposite of the convenience assistant: it does not reduce the cognitive effort, it focuses it. It does not do the work in the decision-maker's place, it gives them the tools to do their own better.

The decision-maker at the center: human in the loop as structural posture

The product's name contains its principle. UBcore: "You Be The Core", you, decision-maker, are the center. The system works for you, never in your place.

This is not a contractual clause, it is an architectural choice. UBcore is designed so that the decision-maker remains the only one who decides. The system brings angles they had not considered, articulates the choices from different perspectives, flags where the initial formulation might contain a blind spot, and then stops. Decisions are not recommended, suggested, automated. They are returned to the decision-maker in a more articulated form than they entered, to be made by them.

The principle of the Human in the Loop, the human in the decision cycle, is not an ethical compromise added afterward. It is the structural posture of the product, written into its shape from day one.

The reversal of the flow

There is a precise sign that tells when you have entered the third paradigm. The flow reverses. The decision-maker stops being the only one asking questions. The model, when it understands it has before it a request for reasoning and not for an answer, begins in turn to ask: to clarify an assumption, to name the constraint that weighs most, to make explicit a decision criterion that had not been declared.

This shift is verifiable in a few minutes. You open a latest-generation model (Claude, GPT, Gemini) and pose a choice to it, rather than a question. "I am assessing entering the [country] market. Help me see the decision: what options do I have in front of me, and what questions should I ask myself before choosing them." Nine times out of ten, the model builds the perspectives and then comes back: "before closing, do you want me to go deeper on angle [Y]? I would need to know whether [constraint Z] is negotiable or not.". It is a different tool. Same AI, different behavior. The difference does not lie in the model, it lies in the framework with which it is questioned.

The same AI, two different results

It shows with a direct example.

A decision-maker who opens Claude or GPT in the oracle paradigm: "Should I acquire company [X]?". They receive a concise analysis with generic pros and cons, a tendentially cautious recommendation, a series of standard risks.

The same decision-maker, on the same model, in the thought partner paradigm: "I am assessing the acquisition of [X]. Articulate for me the three angles from which I should look at it: sustainability of the target's business model over three years, strategic dependence of their technology on [specific constraint], reversibility of the choice if the market changes course. And tell me where my initial reading might be biased by what I have already decided without knowing I had decided it.". They receive something completely different: three structured perspectives, each with its supporting and opposing factors, an explicit note on two or three blind spots that the initial formulation betrayed.

Same model. Same interface. Different tool. The difference is made by the user's cognitive framework.

The examples above show that the cognitive framework changes the tool's behavior even when the model is generalist, with no company context. That is the first step. What UBcore adds is the second: the same cognitive framework, applied to a system that already has the customer's strategic constitution, its document base, the memory of the previous conversations. The difference between questioning a generalist model and questioning UBcore is the difference between a generic external consultant and a consultant who has worked with that company for years.

Why this changes the product category

The AI products for structured companies available today are designed for the first or the second paradigm. They are optimized for speed of response, quality of output, integration into operational flows. They are evaluated with metrics that derive from those paradigms: latency, quality of the single response, coverage of documented use cases.

A product designed for the third paradigm, thought partner, has completely different properties. It optimizes the quality of the reasoning process, before the speed of the response. It maximizes the continuity of memory between successive interactions, because remembering what was discussed yesterday matters more than answering immediately today. It knows when it does not know, and declares it, because the quality of a strategic decision depends also on being able to distinguish what is certain from what is hypothesis. It places the decision-maker at the center of an articulated process.

These are different requirements. They demand a different architecture.

UBcore was designed for the third paradigm from the start. The next section describes what it means, in detail, to design for a thought partner: which sources of intelligence the system brings into dialogue, how it is organized inside, how it speaks with the customer's company systems.

4. What UBcore is

UBcore is a tool that the decision-maker keeps alongside throughout the working day. In the form of a chat, but built on top of an architecture that lets it do very different things: from the quick retrieval of a piece of information to structured support for an important strategic choice. It works with the DNA of the company of the person using it, and never leaves it.

The pages that follow describe what it does in the decision-maker's real day, which sources of intelligence it brings into dialogue, how it is organized inside, and how it speaks with the customer's company systems.

Horizontal work: the backbone of the everyday

For most of the time, UBcore works on the operational plane. Intelligent retrieval of documents from the company's assets. Cross-comparison between contracts and procedures. Compliance check between a draft policy and the one in force. Summary of a series of previous conversations before a meeting. Combined reading of emails, operational documents and system data to answer a concrete question. A contract, like any document, is a wall of text: UBcore does not return the wall, it extracts the datum that is needed and says which line it comes from.

It is the register where the decision-maker builds trust in the tool. The requests are concrete, the answers are verifiable, the response times are short. An average day of a general manager may include twenty or thirty interactions of this kind. The tool enters the workflow and accelerates it.

Strategic moments: where the register changes

An average day also contains two or three moments that carry a different weight. An acquisition assessment. A positioning choice. A capital decision. A repositioning in the market. The preparation of a board meeting on a delicate topic.

For those moments, UBcore changes register. It still retrieves information and data from the documents, retrieves more of it, and puts it under tension with one another. It still summarizes, with more care, because the decision the decision-maker is building depends on how well the picture has been articulated. Above all, in those moments UBcore activates the cognitive framework of the previous section: it comes back with clarifying questions, articulates the same choice from different angles, flags where the initial formulation might contain a blind spot.

The decision-maker works at another level. The tool is the same, it has only understood that it is time to change register.

The Decision Quartet

A thought partner never trusts a single model. In the moments that deserve weight, UBcore does not limit itself to answering: it puts the reasoning under tension. It does so through a coherent family of four independent patterns, the Decision Quartet, each of which stresses a different aspect of the answer. The decision-maker activates them according to what is at stake in the decision.

Dialectic puts thought under tension. The system builds an argued thesis, opposes it in a structured way to its own antithesis, and returns a synthesis picture with the explicit conditions under which one or the other holds. The decision-maker can receive the refined synthesis, or see separately the thesis, the critique and the final synthesis.

Parallel Fact Checking puts facts under tension. It compares what the model states with what web research returns at the same moment. It is the first defense against hallucination, and it works even in the simplest configuration, with a single model.

Parallel Reasoning puts the voice under tension. It questions in parallel two or three models from different providers on the same query, and an impartial judge synthesizes the convergences and flags the divergences.

Parallel Deep Research puts the picture under tension. It combines several reasoning engines with iterative web research, conducted in multiple passes, and a judge integrates the overall picture of an articulated question.

Dialectic puts thought under tension. Parallel Fact Checking puts facts under tension. Parallel Reasoning puts the voice under tension. Parallel Deep Research puts the picture under tension. Four ways never to trust a single model.

The Decision Quartet is an architecturally complete system. One pattern, dialectic, is in daily use in production; the other three are in activation, and section 6 states their status without promising timelines. It is the way UBcore works: one pattern at a time, validated in the field before being declared ready.

How much of the Quartet can be activated depends on how the customer brings their own access keys to the AI models. A single key to one provider activates dialectic and fact checking. A key to an aggregator of several models, or several keys to different providers, activates the entire Quartet. The system does not constrain the choice: it is independent of the vendor by construction, and the customer remains the holder of the contracts with the providers it uses.

Above the four patterns, UBcore is building an orchestrating agent that employs them as tools of a longer reasoning. It is work in progress declared openly, described in section 6.

The distinctiveness: same tool, two registers

UBcore is not distinguished by horizontal work taken on its own: good document assistants for structured companies exist on the market. It is not distinguished by the strategic moments taken on their own: dedicated decision intelligence frameworks exist. It is distinguished by the fact that the same system does both without the user changing tool, context, or language.

The same UBcore that in the morning retrieves the data from a contract, in the afternoon helps articulate a positioning choice. Same customer identity, same strategic constitution, same evaluation criteria, same memory of the previous conversations. The decision-maker does not explain again who their company is when moving from the operational register to the strategic one: UBcore already has it, because it already had it in the morning.

This continuity is what makes the tool useful at the scale of the real working day. No switching tabs. No exporting context. No reformulating the prompt from scratch.

The cognitive lenses

UBcore distinguishes the way it responds depending on the request. When the decision-maker asks for a document verification (a compliance check, citations of an internal policy, the conformity of a draft), the system enters the Verifier register, and the answer arises from the customer's document base. When they bring a quantitative estimate (a projection, a P&L, a price scenario), it enters the Analyst register. When they bring a market choice or a trajectory hypothesis (an acquisition, a repositioning, an opportunity assessment), it enters the Visionary register. When they ask for a text to send (an email, a memo, a post), it enters the Communicator register. When they want to be challenged, not to be proven right but to stress-test their own reasoning, it enters the Red Team register. For everything else, the system stays in the base register, Synaptic Core.

The transition between registers is automatic. A two-level classifier (one deterministic, based on patterns in the decision-maker's writing; one cognitive, based on the meaning of the request) decides which lens to activate, and proposes the chosen register to the user. The user confirms or changes lens. The classifier is calibratable at the customer level: the confidence thresholds, the active lenses and the matching rules can be modulated by the tenant administration through the control console described further on.

Above the main classifier operates a second tactical classifier, which decides whether the current request needs fresh information from the web (a market event of the week, a regulatory decision just announced) or a structured in-depth research, and in that case activates the dedicated module.

The Co-Pilot: the system that explains itself

A cognitive platform is useless if the people using it do not know how to use it. For this we built a second conversational agent, separate from the main work chat, dedicated to explaining UBcore itself. We called it Co-Pilot.

The Co-Pilot knows the product's operational manual, generated automatically from the code and updated with every change to the interface. But it is not a manual: it is a consultant. When the user brings a system question ("how do I configure the Verifier lens for my legal department?", "what is the difference between the DLP Master Switch and the custom DLP rules, and when do I use one or the other?"), the Co-Pilot does not answer with step-by-step instructions. It answers like a consultant: it explains the possibilities, indicates the trade-offs, suggests the right path for what the user is trying to do.

And when it can, it acts directly. If the user says "I want to do an in-depth research on X", the Co-Pilot does not explain how Deep Research is activated: it launches it. If the user asks "show me the state of the memory", the Co-Pilot does not explain where to find the panel: it opens it. It is an agent, not a talking manual.

The Co-Pilot serves three profiles: the user who is learning to work with the system, the administrator who configures their tenant, and the decision-maker who wants to build complex prompts for the system's advanced capabilities. It is distributed onboarding: the product explains itself, at any moment, to anyone who uses it.

The sources of intelligence

UBcore brings into dialogue up to five sources of knowledge, depending on the deployment scenario:

1. What the AI model knows: knowledge of the world, industry best practices, the reasoning patterns learned during training. It is the base substrate, common to any AI assistant.

2. Fresh information from the web, when the question requires it. For factors that change in real time (a market event, a regulatory decision just announced, news about the industry) the model alone is not enough. UBcore decides on its own initiative when to activate the external research, and openly declares when it has done so.

3. The company's information assets: operational documents, contracts, emails, financial statements, reports, lightweight management systems, internal databases, document systems. UBcore does not just ingest the documents: it extracts the concepts that run through them, identifies the relationships that connect them (a document that updates another, a procedure that depends on a regulation, a decision that contradicts a previous decision), and organizes the assets as a navigable knowledge graph, not as a flat archive.

4. The company's constitution: values, principles, strategic postures, the decision-maker's choice criteria. It is the level that differentiates UBcore from any generalist AI assistant. The constitution is structured into two components: a foundational memory (the company's axioms, the operational directives, the non-negotiable criteria) read by the system before every answer; and a documentary asset organized into thematic drawers on three planes: the strategic truths (the backbone of the company, modifiable only by the administration), the operational documentation (the daily circulation), and the project context of ongoing work (the living plane, which changes week by week).

5. In a partner scenario: the output of the system partner's agentic automations (see section 2). When UBcore lives above the automations built by an AI boutique or a system integrator, their output (reports, dashboards, already-processed data) becomes a fifth source of raw materials that feeds the cognitive layer. UBcore does not duplicate the partner's work: it uses it.

The fourth source is the one that makes the difference. Without it, UBcore would be a good generic AI assistant well configured. With it, it reasons like that specific company. The fifth is the one that opens the partner ecosystem: in deployments in complex scenarios, UBcore does not build connectors toward the transactional systems, it uses the output of the partner that already mans them.

The Foundational Layer

Between the customer's raw documentary sources and the plane on which UBcore reasons there is a first-class architectural layer. UBcore calls it the Foundational Layer. It is not external consulting sold separately: it is a component of the product.

All AI systems for companies promise the same thing: connect your data and go. In the reality of structured companies that jump, from knowledge scattered across spreadsheets, shared folders and people's heads to a company that reasons, is enormous. It is not made without a path. UBcore codifies that path as part of the product, in five steps:

• Discovery: the mapping of the knowledge that already exists within the customer: where it lives, in what form, who tends it.
• Strategic constitution: the top of the company formalizes its non-negotiable principles, the choice criteria, the postures that do not change.
• Selection of the foundational documents: the identification of the narrow core of documents that constitute the company's backbone.
• Operational expansion: the operational documentation enters the base under quality control.
• Project context: the ongoing work populates the living plane of memory, the one that changes every week.

The Foundational Layer precedes the cognitive plane described below, and comes first for a reason: it is the grammar on which the reasoning rests. First the grammar, then the reasoning. Without grammar, no answer is truly reliable.

The internal knowledge base: quality that goes in, quality that comes out

Above the customer's company systems, UBcore builds and manages its own vector knowledge base: a structured cognitive asset, where the customer's documents are ingested, broken down into concepts, indexed semantically, and put into relationship with one another.

The knowledge base is organized on the three planes described above (strategic truths, operational documentation, project context). The system reads the high plane with priority and modulates all answers accordingly.

The underlying principle is one of the oldest in computing, Garbage In, Garbage Out, applied to strategic reasoning. The quality of the thinking that UBcore returns depends directly on the quality of the foundational plane that feeds it. For this, the onboarding phase of a new customer is not the installation of software: it is the consultative construction of the foundational plane, side by side with the decision-maker. It is the phase to which the most care is devoted, and where the value of UBcore takes shape before the first conversation is started.

Above the knowledge base operates a continuous verification system, the Seismograph, which monitors the internal consistency of the assets: it flags contradictions that have emerged between documents, evolutions that have made previous versions obsolete, drift between what is declared in the constitution and what emerges from the operational documentary flow. The quality of the base is not an initial state, it is a property maintained over time.

How it is organized inside: the seven internal levels

Turning five raw sources into the decision-maker's structured thought requires an internal architecture. UBcore is organized into seven interconnected levels, each with a specific cognitive function. They are dimensions of one and the same organism, and their strength lies in the way they speak to one another.

The seven levels are dimensions of one and the same cognitive organism. A request that crosses the system touches all of them, in a coordinated way.

The decision-maker's memory

UBcore's memory is not a record of past interactions. It is a cognitive asset that grows over time. Every conversation of the decision-maker with the system is archived, summarized, and indexed for future retrieval. Every document ingested into the knowledge base is read, broken down into concepts, put into relationship with the previous documents, and indexed both for semantic search and for navigation between correlations.

The system combines three retrieval mechanisms (search by semantic meaning, search by exact keyword, and navigation of the relationships in the graph) and orchestrates them automatically depending on the question. For the decision-maker, the effect is that the system remembers: not the way a digital archive remembers, but the way a consultant who has worked with them for years remembers.

The asset is also explorable visually. The decision-maker can navigate their own knowledge as a three-dimensional graph (documents as nodes, correlations as edges), open a document, see which other documents connect to it by analogy, dependency or contradiction, and visually walk through the relationships that the system has extracted.

Memory Cosmos: the web of relationships

This web of relationships has a name: Memory Cosmos. It is the graph that lives above the customer's document base and recognizes its weave: how the documents speak to one another. Every relationship is typed, and carries with it three attributes: a degree of confidence, the indication of whether it is explicit or inferred by the system, and a date. The relationship types are many: a document contradicts another, supersedes it, updates it, derives from it, depends on it, cites it, aligns with it. Each node is also associated with a state in time (active, superseded, archived), so that the system always knows which version of a company position is the one in force today, and why.

It is the difference between an archive and a memory. An archive keeps everything in the same way. Memory Cosmos knows that this year's strategic plan has superseded last year's, and that a set of minutes that still cites the old plan must be read with that awareness.

Sample output, UBcore in dialectic mode. Corpus: Falco Aeronautics S.r.l. Extract.

In answering a top-level question on the management of the financial contraction, the system notes:

"The minutes of the Board of Directors that justify the recent financial measures still cite the previous Strategic Plan, now superseded. Any internal communication on missed and future targets must rely on the Revised Strategic Plan 2026-2028 to avoid formal inconsistencies."

The note was not in the question. It emerges from reading the documentary chain between the board minutes and the filed strategic plans, with awareness of the version in force.

It is Memory Cosmos at work (the recognition of the documentary chain and of the supersession) and, together, the system's dialectic: the way the note is formulated and returned to the decision-maker.

Cognitive hygiene: the knowledge base that stays alive

A company knowledge base, left to itself, ages silently. Documents that contradict each other, updated procedures that coexist with old versions, superseded regulatory references that no one has removed, knowledge that has become obsolete without the organization noticing. It is a form of documentary entropy that, if not controlled, undermines the quality of any cognitive system that works on top of it.

UBcore includes a cognitive hygiene function that actively monitors the state of the knowledge base: it flags to the decision-maker the references that have evolved over time, the contradictions that have emerged between updated documents and previous versions, the areas of the assets where the knowledge base is aging, the orphan documents that no one updates anymore. The company's knowledge is kept alive: not as a state, but as a practice.

How UBcore speaks with company systems: MCP

UBcore is designed to speak with the customer's company systems through an open standard called Model Context Protocol (MCP), developed by Anthropic at the end of 2024 and adopted over 2025-2026 by the main artificial intelligence vendors: Microsoft, Google, OpenAI. The standard works as a universal connector: any system that exposes an MCP interface is readable by the model without having to write proprietary integrations from scratch.

UBcore's commitment is to open standards, not to a specific protocol. MCP is today's: if the standard changes, UBcore will follow the standard, it will not stay tied to a name.

The way MCP is used depends on the deployment scenario, already described in the Sources of Intelligence: in mid-market SMEs UBcore reads the customer's document systems directly; in contexts with a system partner, UBcore relies on the partner's automations, which in turn access the complex systems (SAP, Salesforce, vertical proprietary systems). UBcore does not duplicate the partner's work: it lives above it. UBcore does not speak with the transactional systems. It speaks with those who orchestrate them, or with the document systems sufficiently standardized to be accessible via MCP.

The specific MCP connectors for the most widespread company systems are active work in progress. Section 6 (Guarantees and active work in progress) states the status of that work in detail.

The customer's control tower

We have structured the customer's administration console into nine modules, each dedicated to a specific configuration domain.

• Neural Core: where the brain of the bot lives. The main prompt, the six cognitive lenses with dedicated instructions and models for each register, the company's constitution (its founding values and operational directives) that the system reads before every answer.
• Knowledge & Training: where documents are uploaded and the knowledge base is organized.
• Defense & Compliance: where the behavioral guardrails and the rules for preventing the loss of sensitive information are configured.
• Infrastructure: where the underlying AI providers and the routing between them are configured.
• Organization: where users, roles and permissions are managed, on a matrix of thirty-eight distinct permissions articulated along two axes: capability (base, power, master) and console (none, tenant administration, system administration).
• Capabilities: where the external connectors are registered: the systems that UBcore calls via Model Context Protocol and the systems that can call UBcore via webhook.
• Command Center: analytics of use and performance.
• Cost Console: economic governance: monthly caps per function, automatic audit of the providers' prices, consumption per user in a format compliant with regulations.
• Mode Classifier: calibration of the thresholds of the lens classifier.

Above the nine modules, a Defense Grid lets the customer switch on and off independently the main pillars of the system (memory, in-depth research, data loss prevention, audit, behavioral guardrails, visual navigation of knowledge, decision engine) through a central control panel. The governance of AI risk is a declared and configurable property, not an operational compromise hidden under the hood.

The frontier of models

The same reasoning capability that lets a frontier model solve high-level technical problems (analyzing complex code, identifying security vulnerabilities invisible to an expert human eye, articulating scientific hypotheses) is exactly the one needed when a decision-maker brings a difficult strategic choice to a cognitive layer.

A first-generation model, faced with the daily horizontal work, is enough. Faced with the strategic work in the moments that matter, it is not enough. UBcore is designed to make use of the frontier of models precisely in the moments when the highest level of reasoning is needed. The more the models advance, the deeper UBcore can go: the cognitive layer is designed to grow with them, not to depend on a specific version.

Independence from vendors and data sovereignty

UBcore is not tied to a single AI vendor. The internal architecture includes a multi-provider router that allows every request to be served by choosing the most suitable model, among commercial frontier models and local models run on-premise. Changing provider, because a new model has come out or because the prices of the current vendor have changed or because the customer's posture toward a vendor has changed, is a configuration operation. Not a rebuild.

On the data plane, the rule is symmetrical. The company data (operational documents, the decision-maker's conversations with the system, the Memory that accumulates over time, the strategic constitution) remain the customer's. They are exportable in standard formats, at any moment. They are portable into another system, if the customer decides so. UBcore is a tool for thinking, and thinking belongs to those who produce it.

The two principles, independence from the vendor and data sovereignty, are structural properties of the architecture, written into the shape of the system. Section 6 states their operational and contractual guarantees.

Cost control

Among the causes that strand an AI project, surveys often cite costs that get out of hand: consumption that grows without anyone seeing it, until the invoice arrives.

UBcore treats spending as something to govern, not to endure. The customer sets a monthly ceiling for each capability: beyond that threshold the capability stops, it does not overspend. The system checks the AI providers' prices on its own and flags when they change. Consumption is readable per user and per capability, in a format that can be taken to the finance office.

It is not a dashboard on the side. It is the same posture as the rest of the system: the decision-maker stays at the center, of the tool's economics too. They know how much they spend, they know where, and they have a brake that responds.

5. How UBcore was built

UBcore was designed and built by a single person, in close collaboration with latest-generation artificial intelligence systems, over the span of about twelve months. The platform described in these pages is the result of that path.

Building it with the traditional model (a development team, a product manager, a delivery infrastructure, a roadmap of quarterly milestones) would have required significant investment and time. It would have reached half of the perimeter described in these pages, and in all likelihood with a cognitive framework different from this one.

The factor does not lie in the founder

The factor that made this path possible is the way AI was used.

For twelve months, the founder worked with frontier artificial intelligence systems, from different providers, in parallel, in the register described in section 3: as a thought partner. For every architectural decision of a certain scope, the AI was questioned from opposing perspectives. For every strategic doubt, it was forced to make explicit the assumptions it took for granted. For every product choice, it was made to argue against itself: one day advocate of the go, one day advocate of the no-go.

The cognitive framework that the document describes as a commercial asset is the same framework with which the product was built. A daily practice of twelve months, applied to the construction of itself.

The difference between a platform and a prototype

The method described here drew on AI engineering standards applied with discipline: conscious architectural choices, validated before being implemented, documented before being delivered. The result is a system with structural properties verifiable at the code level:

• Multi-provider router that allows every request to be served by choosing the most suitable model, without dependence on a single vendor.
• Data isolation per tenant at the database level, not at the application level: the data of different customers live in separate zones of the schema, and every request is filtered structurally to prevent access to the data of another tenant.
• Granular access governance: thirty-eight distinct permissions that modulate what each role can see and do, configurable for each customer.
• Automated tests in continuous integration: every change to the code is validated by a battery of tests before entering the system in operation.
• Documentation that is generated from the code: the components of the interface carry structured comments that the system extracts automatically to build the Co-Pilot's internal manual. If the interface changes, the documentation changes with it, without manual intervention.

UBcore, UBcore's first customer

During the twelve months of construction, the founder brought the decisions of their own project to the cognitive layer: choices of product, of positioning, of architecture. They received angles they had not considered. They changed course on some choices, reinforced others, recognized where their initial reading was biased by a blind spot. This was the first proving ground of the method described in these pages.

6. Guarantees and active work in progress

UBcore is a platform in operation. It is also a laboratory: there is work in progress, there are things in piloting, there are things in development. This section states, with precision, what belongs to which category.

Guarantees of operability

The system properties that today sustain the daily functioning of the first customer (service availability, data security, regulatory compliance) are formalized case by case with each new customer, according to the specifics of the deployment.

The data processing model is compliant with European regulation, and the customer's rights over their own information base are explicit at the contractual stage.

Protection of intellectual property

A company's constitution (the choice criteria, the strategic postures, the decisional precedents codified in the system) is an asset that the customer builds over time. The structural properties that protect its integrity (granular technical access controls, data isolation per tenant at the database level, two-axis governance) are described in the previous section. To these is added an audit log system that traces the system's administrative and governance actions, and contractual commitments that explicitly recognize the customer's ownership of their own cognitive base. The system also has an engine for preventing the loss of sensitive information (DLP), activatable for scenarios that require it.

Regulatory framework and compliance

UBcore operates within the European regulatory framework. The processing of personal data follows the GDPR (EU Regulation 2016/679): declared purposes, explicit legal basis, exercisable data-subject rights. For customers in regulated sectors, the specific data-processing agreements are formalized case by case.

On the artificial intelligence side, the system is designed in line with the principles of the European AI Act (EU Regulation 2024/1689): human oversight, traceability of decisions, transparency, risk governance configurable by the customer. These properties are structural: the Human in the Loop, the explicit citation of sources in every response, the Defense Grid that leaves the activation of each pillar to the customer.

The customer's data does not feed the training of the models. The AI providers used by UBcore, under the terms of service of their respective APIs, do not use input data to train the models. For contexts that require full data sovereignty, UBcore is ready for on-premise deployment, with local models and no flow toward external providers.

Continuity of service

A cognitive platform asks the system partner for the trust that the vendor will still exist five years from now. For this, UBcore prepares with the integrator partners a Successor Readiness Pack: a documentary package that codifies UBcore's vision, the main architectural decisions, the operational protocols, and the criteria for the replicability of the work.

The package is structured so that, in any future scenario (continuation of the project, sale, internalization at the partner, transition to a new system team), the partner has the documentation needed to guarantee continuity in the operation of the cognitive layer toward its own end customers.

How we measure that it works

A platform that works above a company's decisions is not validated with common sense. We adopt a structured evaluation methodology, based on test corpora annotated with ground truth, precision and coverage metrics measured against declared references, and multi-model separation between the system that generates the test cases, the system that produces the answer, and the system that evaluates the quality. The effect is that no model judges itself.

For customers operating in regulated sectors, where the quality of the answers has legal implications, we have defined an advanced validation protocol, based on comparing the system's answers with those of human experts of the specific domain. We are interested in building the first real cases of application of the protocol in collaboration with partners that bring customers from their own sector of expertise.

What is in operation today

The cognitive layer described in these pages works daily in a first real deployment, at an Italian company in the creative sector. The main structural properties (the seven internal levels, the multi-provider router, the access governance, the document ingestion, the decision-maker's semantic memory, the vector knowledge base and the system for verifying its quality) are part of the current operating record.

The customer can switch on and off independently the main pillars of the system (memory, visual navigation of knowledge, in-depth research, data loss prevention, audit log, behavioral guardrails, decision engine) through a central control panel described in section 4. The calibration of the active pillars is an explicit choice of the customer.

What is in piloting

Some capabilities are in the phase of being refined in the field before the full contractual exposure: the Model Context Protocol as a standard for reading the customer's company systems, and the scientific validation framework.

Advanced agentic orchestration is also active work in progress: the system's capability to break a complex request into coordinated sequences of subtasks, execute them with different tools, and account for them to the decision-maker. The work proceeds in public on UBcore's channels.

What is in development

Other capabilities are declared openly as work in progress: the specific MCP connectors for the most widespread company systems, the administrative coverage for more structured scenarios, and the three patterns of the Decision Quartet not yet in operation: Parallel Fact Checking, Parallel Reasoning and Parallel Deep Research. Dialectic, the first of the four patterns, is instead already in daily operation.

UBcore works with an incremental approach: every new piece of work is activated when a real customer requests it, avoiding the building of speculative integrations that would remain unvalidated. The status of each piece of work is stated explicitly in the pre-sales conversations and in the operational contracts. No function described in these pages is taken as in operation by omission: what is in piloting or in development is declared as such, always.

Materials for technical qualification

For the partners and interlocutors who assess UBcore before an operational conversation, beyond this White Paper there is extended technical and operational documentation available: architectural details, technical qualification dossiers, the product's operational manuals. The documentation is shared case by case, after an initial conversation, calibrated on the profile of the interlocutor.

7. Posture and invitation

The laboratory behind UBcore works without hype. It builds, releases, and learns from real customers in production. It looks for interlocutors who can read an enterprise-grade architecture applied to the decision-maker of a small or medium-sized company, and who recognize the problem before being convinced.

The partnerships we seek are articulated by profile.

AI boutiques and advanced system integrators live in the layer of the customer's operational automations. Adding the cognitive layer to their portfolio means being able to address a different interlocutor within the same customer: no longer only the IT manager assessing a new automation, but the leadership looking for a tool for strategic choices. The interlocutor changes, the conversation changes, the relationship with the customer changes. The two pieces of work are complementary, never overlapping: the partner brings the process automations, UBcore lives above them.

Strategic advisors and operating partners with real clients and established top-level relationships, who recognize in the cognitive layer a tool to introduce into the conversations they already lead. With these figures we seek a dialogue: to meet, to read the problem together, to understand whether there is ground for what may come next.

In all cases, the posture is the same: interlocutors who recognize the problem before being convinced. The aim of this document is to put the reader in a state in which the open questions of these pages become their own. From there on, the conversation is direct.

UBcore is a tool. The question comes first.