Skip to main content

Docs wiki

Docs is TOW's native wiki for long-form company context. Use it for material that people should read, maintain, search, cite, and use as source material for Memory.

Docs is best for:

  • Product briefs, strategy notes, and market context.
  • Customer research, calls, and implementation notes.
  • Technical plans, architecture context, and operating playbooks.
  • Policies, process docs, and onboarding material.
  • Meeting notes that should become searchable workspace context.

Use Memory for concise durable facts. Use Docs for the surrounding explanation.

Docs tree​

The Docs tree shows pages in a hierarchy. Use it to keep related context together and make ownership easy to understand.

Common patterns:

  • A top-level page for a product area, customer, team, or operating function.
  • Child pages for research, decisions, implementation notes, and follow-up plans.
  • A project-scoped tree for work that should not be mixed with company-wide docs.
  • A short index page when a folder has many child pages.

You can create, duplicate, move, change scope, make private, archive, delete, and extract memory from pages in the tree or from the page actions menu.

Project scope

The Docs tree follows the current project scope. If a page is missing, confirm whether you are in All Projects or a specific project. Create project-specific docs inside the project that owns the work; create company-wide docs at the organization level.

Scope breadcrumbs and moves​

Every doc title shows a location breadcrumb before the title, for example Organization / Docs / Parent / Current, Project TOW / Docs / Current, Group Engineering / Docs / Current, or Private / Docs / Current. The first breadcrumb tells you where the doc lives; parent breadcrumbs open ancestor docs.

Use Move / change scope to move a doc within its current tree or change it to organization, project, group, or private scope. Use Make private when the doc should become private to you. Scope changes are recursive: the selected doc and all nested child docs move together, and child docs always keep the exact same scope as their parent.

When changing scope, review the destination parent and the affected child count. Access can change for the whole subtree, especially when moving between projects, groups, and private docs.

Editor​

The Docs editor is for structured writing, not just raw notes. Keep pages readable for both humans and AI.

Good doc structure includes:

  • A clear title.
  • Short sections with descriptive headings.
  • Bullet lists for constraints, decisions, risks, and next steps.
  • Links or reference IDs for related memory, tickets, decisions, risks, snapshots, or other docs.
  • A short summary at the top for long pages.

Avoid storing unrelated topics in one large page. Separate pages create cleaner search results, backlinks, revisions, and memory extraction.

Autosave​

Docs edits are saved automatically. Autosave helps preserve work while you write, and each meaningful saved change can become a revision.

Use autosave with care:

  • Pause briefly after major edits so the save can complete.
  • Check the page title, body, and references before relying on the page.
  • Watch for Agent running indicators after create, update, restore, archive, or extract-memory actions.
  • If two people edit the same page at the same time, coordinate before replacing large sections.

Autosave does not mean generated or draft content is approved. It means the doc page has been saved.

Revisions​

Revisions preserve earlier versions of a doc. Use them to inspect what changed, recover accidentally removed content, and understand the source history behind extracted memory.

Revision history is useful when:

  • A page was edited after a customer call or strategy change.
  • A generated update changed wording too aggressively.
  • You need to restore an earlier version.
  • Memory extraction created facts from a version you want to inspect.

Restoring a revision updates the page and can trigger processing. Review the restored page before extracting memory or making decisions from it.

Archive​

Archive a doc when it should no longer appear in normal docs lists or search results, but the page should remain available as historical context.

Archive is appropriate for:

  • Old strategy notes.
  • Completed project plans.
  • Deprecated technical context.
  • Pages that should not guide current work but may explain history.

Archived docs can still matter because memory, references, and revisions may point back to them.

Delete​

Delete removes a doc page and its associated doc records. Depending on the action you choose, child docs may be kept and reparented or deleted recursively. Related memory can also be archived as part of deletion.

Use delete only when the page should be removed rather than retired.

Archive vs delete

Archive is the safer default for stale knowledge because it preserves history. Delete is stronger: it removes the doc from docs, revisions, backlinks, and search. Before deleting, review child docs and related memory so you do not remove evidence that explains current workspace state.

Child docs during delete​

When deleting a doc with nested pages, decide whether child docs should be kept or deleted too.

  • Keep child docs when they are still useful and should move up in the tree.
  • Delete child docs recursively when the whole subtree is obsolete or must be removed.
  • Review the count of affected child docs before confirming.

If you keep child docs, check the tree afterward so the remaining structure still makes sense.

Docs can be source material for Memory. When deleting a doc, TOW can archive memory extracted from that doc.

Extracted memory

Deleting a doc does not automatically mean every extracted memory item is false. Some extracted facts may still be current, especially if they are supported by other sources. Review related memory before archiving it during deletion.

Archive related memory when the source page was the main evidence and the fact should no longer guide work. Keep related memory when the fact remains true or is backed by other docs, tickets, decisions, or snapshots.

Extract memory​

Extract memory asks TOW to scan a doc for durable facts and propose memory changes. It does not immediately make all extracted facts trusted memory.

Use Extract memory after:

  • Writing a product brief or strategy update.
  • Capturing customer research.
  • Recording a technical decision or constraint.
  • Updating an operating policy.
  • Restoring or substantially editing a doc.

After extraction, review the resulting memory diff. Approve only the facts that are accurate, durable, scoped correctly, and useful enough for Memory.

AI-generated content

Memory extraction uses AI to identify candidate facts. The output may omit important context, phrase assumptions too strongly, or extract details that should remain in Docs. Review each proposed memory diff before accepting it.

Docs can contain reference IDs for memory, docs, tickets, snapshots, decisions, risks, and events. When a page includes a recognized display ID, TOW indexes it as an outgoing reference. Other pages that point to the current doc appear as backlinks.

Use references when:

  • A doc depends on a decision, risk, or ticket.
  • A plan should cite the memory that supports it.
  • A customer note should link to the implementation project.
  • A strategy page should point to the active snapshot or key risks.

Backlinks help you understand where a page is being used before editing, archiving, or deleting it.

Healthy wiki habits​

For enterprise workspaces, a healthy Docs wiki is current, scoped, and easy to audit.

Recommended habits:

  • Keep titles direct and searchable.
  • Split long pages when topics diverge.
  • Add reference IDs for important dependencies.
  • Archive stale pages instead of letting outdated guidance appear current.
  • Extract memory only from reviewed source material.
  • Review backlinks before major edits or deletion.
  • Use project scope intentionally.