Skip to main content

Search and references

TOW connects knowledge through search, references, display IDs, and backlinks. These tools help you inspect the evidence behind answers, understand dependencies, and move from a summary to the source records that support it.

Use search when you need to find context. Use references when you need to verify or connect context.

Search works across knowledge surfaces such as Memory, Docs, snapshots, tickets, decisions, risks, and events, depending on the view you are using.

Use search to:

  • Find what TOW currently believes about a topic.
  • Locate the doc or memory item behind an AI answer.
  • Check whether a fact already exists before adding new memory.
  • Find stale pages before archive or cleanup.
  • Review all context related to a customer, project, product area, risk, or decision.

Search results are strongest when titles, headings, tags, and reference IDs are clear.

Search by view

Different views answer different search questions.

ViewUse it for
MemoryDurable facts, assumptions, constraints, priorities, risks, and source-backed facts.
DocsLong-form context, wiki pages, research, briefs, and operating notes.
SnapshotsCurrent or historical summaries of company or project state.
TicketsExecution work, owners, status, blockers, and implementation details.
DecisionsJudgment calls and rationale.
RisksKnown uncertainty, blockers, and mitigation plans.
Global referencesCross-surface lookup by title, text, type, or display ID.

If a search result feels incomplete, check project scope and status filters.

Project scope

Search follows the current scope and filters. A project-scoped search may hide organization-wide context, and an organization-wide search may include facts that are too broad for a project decision. Confirm scope before relying on search results.

Display IDs

Display IDs are short identifiers that make workspace records easy to cite. They usually use a prefix plus a short ID.

Common prefixes:

PrefixRecord type
MMemory
PDoc page
SSnapshot
DDecision
RRisk
EEvent or source event
TTicket, when using TOW references

Tickets may also use Jira-style issue keys such as PROJ-123.

Use display IDs in docs, chat, comments, and reviews when a statement depends on a specific source. They make later verification much easier.

Referencing records

When you include a recognized display ID in a doc page, TOW indexes it as a reference.

Examples:

  • Cite a memory item in a product brief: M1a2b3c4d.
  • Link a roadmap plan to a decision: D4e5f6a7b.
  • Reference a risk in a launch checklist: R9a8b7c6d.
  • Point an implementation note to a ticket: PROJ-123.
  • Link a strategy note to the active snapshot: S2c3d4e5f.

Keep references close to the claim they support. A reference at the end of a long page is harder to audit than a reference next to the relevant statement.

Backlinks show other docs that reference the current page. They help you understand where a page is used before editing, archiving, or deleting it.

Use backlinks to:

  • See which plans depend on a doc.
  • Review downstream impact before changing guidance.
  • Find pages that cite a stale source.
  • Understand why a doc still matters.
  • Clean up references after a project changes direction.

Before deleting a doc, check backlinks. Deleting a referenced page can leave other pages without useful evidence.

References in AI answers

AI answers may include references to memory, docs, tickets, decisions, risks, events, or snapshots. Treat those references as the audit path.

Before acting on an AI answer:

  • Open the cited records.
  • Confirm they are active or otherwise appropriate.
  • Check whether any cited memory is superseded, archived, or pending review.
  • Compare the answer with the source wording.
  • Look for missing project scope or stale assumptions.
AI-generated content

References make AI output easier to review, but they do not guarantee the answer is complete or correct. Use references to verify the answer before making high-impact operational, customer, financial, legal, security, or technical decisions.

Memory basis

Some chat answers show a Memory Basis section. This section lists memory and related records that influenced the answer.

Use Memory Basis to:

  • Identify which facts shaped the recommendation.
  • Find weak or stale memory.
  • Correct source memory after a bad answer.
  • Explain why TOW answered a certain way.

If Memory Basis cites the wrong scope, stale facts, or low-confidence memory, update or archive the source items rather than only correcting the chat response.

Search before creating new knowledge

Before adding a new memory item or doc page, search for existing context.

This prevents:

  • Duplicate memory items.
  • Conflicting docs.
  • Recreating already resolved decisions.
  • Treating stale project notes as new company-wide facts.
  • Losing the connection between source material and extracted memory.

When you find a related record, reference it. When the existing record is outdated, update, supersede, or archive it instead of creating a disconnected replacement.

Canonical records

Different records have different levels of authority.

RecordCanonical when
MemoryStatus is active and scope is correct.
SnapshotStatus is active for the relevant type and scope.
DocCurrent page content is reviewed and not archived.
DecisionStatus reflects the team's current judgment.
RiskStatus and severity reflect current uncertainty.
TicketStatus, owner, and scope reflect current execution.
Canonical state

Search can surface drafts, historical records, pending proposals, superseded facts, and archived items. Always check status, scope, date, and source before treating a result as current truth.

Practical search habits

Use these habits to keep knowledge easy to find:

  • Give docs and memory direct titles.
  • Use consistent customer, product, and project names.
  • Keep high-impact facts in active memory.
  • Add display IDs beside important claims.
  • Archive stale docs and memory.
  • Review backlinks before major changes.
  • Use status and type filters when search results are noisy.

Search and references are the connective tissue of the workspace. The more consistently they are used, the easier it becomes to trust, audit, and update TOW's knowledge.