Traceability

A generated answer can sound convincing even when the reader has little visibility into how it was produced. A citation may show that a relevant source exists, but it does not necessarily explain how the information in that source contributed to the conclusion.

ASUME is designed around a different relationship between information and output. Evidence, assumptions, inferred statements, and the maintained company understanding exist before the final objective-dependent result is presented. Traceability connects those layers so that the output does not become detached from the basis on which it was produced.

At a simplified level, a user can move from an output back toward its basis:

Output → Company understanding → Assumptions & evidence → Source

The exact path depends on the result. Some conclusions may be supported directly by evidence, while others depend on several inferred statements or assumptions. What matters is that the relevant path does not disappear once the output has been generated.

A trace starts with the information ASUME was allowed to use. That information may come from a company website, product documentation, a job post, an announcement, a Customer-authorised source, an internal record, or another available source.

For evidence to remain inspectable, ASUME also needs to preserve relevant provenance: where the information came from and the context necessary to understand it. Depending on the source, that can include the page or document, the relevant observation, when the information was published or observed, and the part of the company to which it applies.

For example, the statement:

The company is hiring machine-learning engineers.

is more useful when a user can also see that it comes from the company's careers material, which vacancies were observed, and when that information was found.

Provenance gives the evidence an inspectable origin. Traceability then connects that evidence to what ASUME did with it.

Showing a source does not necessarily explain a conclusion.

Suppose a company has twenty open implementation roles. The source may establish the hiring activity directly. ASUME may then conclude that the company appears to be expanding its implementation capacity, but that conclusion could also depend on an assumption that most of those positions represent additional capacity rather than replacement hiring.

A source link alone would hide that distinction.

The useful trace therefore needs to preserve enough of the relationship to show:

What was observed?

What was inferred from it?

What had to be assumed?

This is why traceability in ASUME is broader than citation. A citation identifies supporting information. A trace helps explain how that information became relevant to the conclusion.

ASUME outputs are applications of the maintained company understanding. They can include answers, matches, opportunities, recommendations, rankings, explanations, or other results produced for a particular objective.

Suppose ASUME identifies a potential commercial opportunity for a company. A user may first ask:

Why did ASUME identify this opportunity?

The answer may point to a company-level conclusion such as:

Implementation capacity appears to be under pressure.

The user can then ask:

Why does ASUME think that?

That conclusion may be connected to evidence about implementation hiring, customer growth, deployment changes, or other relevant information, together with assumptions that materially affect the interpretation.

Traceability therefore allows a user to move through the result instead of receiving one undifferentiated explanation.

A simplified path might look like:

Output → Relevant company statement → Assumptions → Evidence → Source

Not every output follows exactly the same structure, but the principle remains the same: the result should remain connected to the company understanding from which it came.

Assumptions are particularly important for traceability because they identify where reasoning goes beyond what the available evidence directly establishes.

Suppose ASUME observes significant security hiring and concludes that a company appears to be expanding its internal security capability. If that conclusion depends on assuming that most of the roles represent additional capacity rather than replacements, the assumption materially affects how the conclusion should be interpreted.

Keeping that dependency visible allows the user to distinguish a conclusion that is almost entirely evidence-supported from one that depends on an unresolved step in the reasoning.

It also matters later. If new information shows that the vacancies were primarily replacements, ASUME can reconsider conclusions that depended on the earlier assumption.

Traceability therefore helps assumptions remain useful without allowing them to disappear inside confident language.

Company understanding is rarely built from one source at a time. A conclusion may depend on several observations that become meaningful when considered together.

For example, ASUME may understand that a company is increasing its enterprise focus based on changes in product capabilities, implementation hiring, pricing, customer case studies, deployment documentation, and other relevant activity. Each piece may have its own source and evidential significance.

Traceability allows those relationships to remain inspectable without reducing the conclusion to whichever citation is easiest to display.

A user can therefore see that an interpretation is based on a combination of signals rather than assuming that one source directly stated the final conclusion.

This is especially important for company properties such as needs, priorities, constraints, and direction, which are often inferred from several related observations rather than explicitly announced.

The same maintained company understanding can support different objectives, and traceability needs to preserve the distinction between the underlying company state and the way a particular objective uses it.

Suppose ASUME understands that a company is expanding a technical capability. That conclusion may matter for a Revenue objective because it creates a potential commercial need. The same company state may matter for a Partnerships objective because it changes how complementary another company's capabilities appear.

These are two different questions:

Why does ASUME understand this about the company?

and:

Why did this part of the understanding matter for this output?

Traceability should help answer both.

This prevents objective-specific reasoning from becoming confused with the underlying company understanding. The company state remains reusable, while each objective can explain how that state contributed to its particular result.

A useful trace should not only explain why ASUME holds a conclusion now. When the company understanding changes materially, it should also be possible to understand what caused the revision.

Suppose ASUME previously understood that a company was building an internal implementation capability. Later, the company announces that implementation will be substantially outsourced. The new evidence may change the earlier conclusion.

Instead of simply replacing one answer with another, ASUME can preserve enough context to explain that the understanding changed because the evidential basis changed.

This allows a user to distinguish three questions:

What does ASUME currently understand?

Why does ASUME understand it this way?

Why is this different from what ASUME understood before?

That is particularly valuable for companies that ASUME follows over time, where changing conclusions may reflect real changes in the company rather than inconsistency in the system.

Traceability is also useful when the available information disagrees.

One source may indicate that a company is increasing investment in a market while another suggests that operations there are being reduced. Both pieces of evidence may be legitimate, and ASUME may not yet have enough information to resolve the difference.

In that situation, traceability should not show only the evidence supporting the preferred conclusion. Relevant contradictory evidence should remain part of the understanding when it materially affects the result.

This allows a user to see not only why ASUME supports a conclusion, but also what information weakens or complicates it.

That distinction is important to the broader principle of never hiding the gaps. An explanation is more useful when it exposes meaningful uncertainty rather than constructing a cleaner story than the evidence supports.

Traceability makes verification more useful because it allows different parts of a result to be evaluated separately. Instead of judging only whether the final output looks reasonable, automated evaluation or sampled human verification can inspect the information and relationships that contributed to it.

A reviewer may find that the source is valid but that the relevant observation was extracted incorrectly. The evidence may be accurate while the inference is too strong. The inference may be reasonable but depend on an assumption that deserves more caution. Or the company understanding may be sound while a particular objective used it inappropriately.

These are different kinds of problems, and they require different corrections.

Traceability helps make those distinctions visible. It does not guarantee that every step is correct, but it makes it easier to identify where a problem exists and what may need to change.

A traceable conclusion is not necessarily a true conclusion.

The source may contain inaccurate information. Evidence may be interpreted incorrectly. An assumption may later turn out to be false. An inference may be too strong, or new information may change what the earlier evidence means.

Traceability does not remove these possibilities. Its purpose is to make the basis of the conclusion inspectable.

The distinction is therefore:

Traceable does not mean proven.

It means that a user can inspect the relevant basis on which the conclusion currently exists.

Whether that basis is sufficient is a separate question for evaluation and verification.

A citation answers an important but limited question:

Where did this information come from?

Traceability answers a broader question:

How did the available information contribute to this particular output?

Consider the output:

This company may require additional implementation capacity.

A citation might link to a careers page showing fifteen open implementation positions.

A fuller trace could show that those vacancies contributed to an interpretation that implementation activity is expanding, that the interpretation depends on an assumption about whether the roles are net-new, and that this company-level understanding became relevant to the user's Revenue objective.

The citation remains useful because it provides the source. Traceability gives that source a place within the larger explanation.

This is why ASUME does not treat references beside generated text as sufficient on their own.

The goal of traceability is not to expose the complete internal implementation of AUM. It is to give users enough visibility to evaluate the basis of what ASUME tells them.

Depending on the output, this can include understanding what information was used, where it came from, what ASUME inferred from it, which assumptions materially affected the result, what uncertainty remains, why the information mattered to the objective, and what changed if the company understanding was revised.

This makes an ASUME output more than a generated answer. It becomes an entry point into the company understanding behind it.

A user can accept the conclusion, challenge it, inspect the evidence, question an assumption, provide better information, or understand why the result changed. Traceability therefore supports not only trust, but also correction, revision, and more informed use of ASUME's outputs.

Traceability does not mean that every source is reliable, every inference is correct, every assumption is valid, or every output should be relied on without review. It also does not mean that displaying a citation beside generated text is enough to explain the result.

It does not require ASUME to disclose hidden chain-of-thought, internal prompts, model weights, proprietary scoring methods, security-sensitive implementation details, or every intermediate computation performed by the system.

The relevant promise is narrower: ASUME preserves enough of the basis of its company understanding to make important conclusions inspectable, challengeable, and revisable.

That is what Every output explained means in practice.