Start with the architecture, then ask what the evidence means

Begin with a system you can point to

A useful first view tells you what exists and how the parts relate. You should be able to point to an application, follow its connection to a datastore, and ask which observation supports that connection. A list of issues cannot answer those questions on its own.

That is why Hyperoru opens the product example on an architecture map. The map is an interface to recorded entities and relationships. It becomes more useful as you connect the sources needed to answer a particular question.

Follow one relationship all the way back

Consider an API that reads from a database. Code can show the database client and the call site. Cloud inventory may show where the database lives. Delivery evidence may connect the deployed service to a source revision. Each observation contributes something different.

Select the relationship, inspect its evidence, and read its observation date. Confidence helps you judge the support behind the claim; it does not turn a partial view into complete knowledge.

• Confirm which source was observed and when.
• Check that the evidence refers to the system and revision you are reviewing.
• Look for missing sources and contradictory observations.

Treat coverage as part of the answer

A source-code review can reveal declared dependencies. It cannot establish every live request path, cloud identity, or runtime condition. The answer should change when evidence is missing, rather than quietly assuming the missing layer agrees.

In the product, Map and Truth show the same underlying records. Coverage explains the scope around those records. Findings can add useful observations, but their severity is not a substitute for a connected explanation.

Bring a question to the first review

Start with something concrete: which service can reach this datastore, or which entry point authenticates requests? Create a workspace, connect an appropriate source, and run a review. Use the resulting map to decide what additional evidence would make your answer stronger.

The first snapshot establishes context. Your team still needs to explain why the architecture was chosen, and a later comparable snapshot is needed to discuss drift over time.