A team deciding on a physical product needs the system assisting it to know its context at least as well as the team does. This document describes the six sources behind every Nodal analysis, how the origin of each data point is recorded and where human judgment enters.
9 min read
Premise
The quality of a recommendation depends, first of all, on the information it is built on. A product team decides with knowledge of its portfolio, its customers, its industrial capacity and the constraints that apply to it. To assist that team rigorously, a system needs the same knowledge and also what the team has no time to gather: current market evidence, industrial references from other sectors and the earlier decisions of the project itself.
This document follows that circuit. It does not describe a capability of the language model, but the information architecture around it.
Why one source is not enough
A general-purpose language model, queried without loaded context, answers from a single source: what it learned during training. The result is usually coherent and well formed, but by construction it is the same for any company asking the same question. A physical-product decision is not interchangeable in that way. It depends on the plant, the customer, the applicable regulation and market facts that postdate the model's cutoff, none of which belong to its general knowledge.
Equivalent for any company asking the same question.
- 01Company
- 02Brief
- 03Nodal base
- 04Model
- 05Research
- 06Project
Built on the team's specific case, with the origin of each data point recorded.
The six sources
They fall into three groups by origin. None is sufficient on its own, and their value lies in each one correcting the blind spots of the others.
Provided by the client
Company context
Portfolio, customers, manufacturing capabilities, constraints and decision criteria. It carries the most weight, because it defines what a good decision means for that company and not for the market in the abstract.
Product brief
Objective, audience, price range and limits of the specific project. It bounds the question the analysis has to answer.
Base knowledge
Nodal knowledge base
A curated body of industrial and business knowledge organised in three domains: business, design and industry. It is consulted when the project requires it and has not been used to train models.
Model knowledge
What the language model acquired during training: technical terminology, reasoning and regularities from very different sectors. It is the source common to any system of this kind; here it is one of six.
Generated during the project
Live research
Agents that, for each project, find, read and cross-check current public sources on market, trends, competitors and users. It covers the interval after the model's cutoff.
Accumulated project context
Each phase produces results that shape the next: brief, research, concept, validation, materials. It is developed further below, under context accumulation.
- 01Company context
- 02Product brief
- 03Nodal knowledge base
- 04Model knowledge
- 05Live research
- 06Accumulated context
Each reviewed result feeds the project (source 06)
Traceability: every data point keeps its origin
Having several sources only adds value if it is possible to tell which one each claim comes from. An analysis whose origin cannot be reconstructed forces the team to accept it entirely or discard it entirely. With the origin recorded, the team can assess each data point separately according to the reliability of its source.
That is why every data point the system provides in Nodal carries its provenance. The table summarises which kind of claim usually rests on which source and what the team should check in each case.
| Type of claim | Usual source | What to verify |
|---|---|---|
| Internal constraint (capacity, lead times, margins) | 01 Company context | That what was provided is still current |
| Project objective and limits | 02 Brief | That the brief reflects current intent |
| Industrial practice or reference | 03 Knowledge base | Fit to the sector and the scale |
| Reasoning and technical terminology | 04 Model | That it does not depend on data after its cutoff |
| Market fact, trend or competitor | 05 Live research | Date and reliability of the cited source |
| Earlier project decision | 06 Accumulated context | That the decision still holds |
Human review: from data point to decision
The system proposes and the team decides. This split is not a formal precaution but a condition of use: the recommendation of an automated system is only useful if whoever receives it can judge it. The literature on interaction with automated systems documents two opposite risks, uncritical acceptance of what the system proposes and rejection through unjustified distrust [4]. Both are mitigated the same way: by giving the decision-maker enough information to calibrate how far to trust each result [5].
The traceability described above is that information. Human review is the point where it is used: the team checks each relevant data point against its origin, applies the judgment the system lacks (the customer's history, the relationship with suppliers, the company's tolerance for risk) and turns the analysis into a decision. That decision is recorded and, through source 06, shapes what the system proposes next.
- Traced by the system01Claimfrom the system
- Traced by the system02Recorded originsource, date, version
- Team judgment03Human reviewchecked with judgment
- Team judgment04Decisionrecorded
The decision becomes project context
Context accumulation across the project
A Nodal project moves through six phases: briefing, market, concepts, validation, visualisation and dossier. Each one inherits the results of the previous ones. By the visualisation phase, the system holds the brief, the market and user research, the trends, the chosen concept, what was decided in validation and the materials and parts of the product. The image and the final dossier are not generated from an isolated instruction but from that whole path.
The mechanism has a technical basis. Language models make poorer use of information when it is handed to them indiscriminately in very long contexts [3], so accumulating context does not mean resending everything before, but keeping and retrieving what is relevant to each phase.
Final decision
Consulting, not training
Nodal's knowledge base (source 03) has not been used to train models. It works as a document store: when the project requires it, the system retrieves the relevant passages and adds them to the model's query. This technique, known as retrieval-augmented generation, has been described in the literature since 2020 [1] and systematically reviewed in later work [2]. Its practical advantage is that the store can be corrected, updated or withdrawn without retraining anything, and that each retrieved passage can be cited as the origin of the data point, which is what makes traceability possible. Retrieval is also a recognised route to reducing the unsupported claims that models produce when they only have what they learned in training [6].
The same principle applies to client information. Their context and documents are used to serve their project, and Nodal does not use them to train its own models or anyone else's.
Coverage comparison
The table compares a general-purpose model without loaded context with the circuit described here. The values reflect the design of each approach, not a measurement of answer quality.
| Dimension | Model without loaded context | Nodal |
|---|---|---|
| Sources feeding the answer | 1 of 6 | 6 of 6 |
| Knowledge of the company | None | Source 01, provided by the client |
| Currency of market data | Limited to the model's cutoff unless search is explicitly used | Live research with dated sources |
| Earlier phases inherited at decision time | 0 | Up to 5 |
| Origin of each data point | Not recorded systematically | Recorded per data point |
| Human review point | Left to each user | Built into the flow, before the decision |
References
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arxiv.org/abs/2005.11401
- Gao, Y. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arxiv.org/abs/2312.10997
- Liu, N. F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the ACL. arxiv.org/abs/2307.03172
- Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3), 381-410.
- Lee, J. D. & See, K. A. (2004). Trust in Automation: Designing for Appropriate Reliance. Human Factors, 46(1), 50-80.
- Ji, Z. et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12). arxiv.org/abs/2202.03629
