Aamu.app Docs is the shared writing and knowledge layer inside the Aamu workspace. A Doc can be an internal note, a project plan, meeting preparation, support knowledge, API-maintained content, or even the source text for a public blog post.

The important point is that Docs are not isolated files. They belong to projects, can be searched, tagged, discussed, linked from other Aamu items, used as Team Brain knowledge sources, and updated through the Aamu API.

Docs belong to projects

The Docs section is project-scoped. You can view Docs in one project or across all projects. A Doc card shows the title, project, owner, status, participants, comments, tags, sharing state, and created/updated metadata.

This makes Docs useful for both personal drafting and shared project knowledge. A product team can keep specs in one project, support can keep answer guidelines in another, and company-wide material can live in a shared project.

Public, draft, and deleted Docs

Aamu Docs currently use simple statuses:

  • Public Docs are visible in the project according to normal access rules.

  • Draft Docs are visible to their owner while they are still being prepared.

  • Deleted Docs are moved out of the normal list and can be reviewed from the deleted view.

The word "public" here means public inside the Aamu workspace context, not automatically public on the open internet. Separate sharing or publishing workflows can expose content elsewhere.

Create and edit

Create a new Doc from the Docs section. The editor supports rich text content, internal links, files and media through the editor, comments, tags, and collaborative editing patterns used across Aamu.

Use Docs when the work needs durable context rather than just a task comment. Good examples include:

  • project plans,

  • meeting notes,

  • support instructions,

  • internal policies,

  • product documentation,

  • draft articles, and

  • knowledge that AI should later retrieve.

Search and unseen Docs

Docs are searchable from the Docs section and from Aamu's broader search. The Docs list also has an unseen view, which helps users notice newly updated or unread Docs in a project.

This matters once Docs become the team's memory. Search lets you retrieve old decisions and instructions. The unseen view helps a team notice changed documents without manually checking every project.

Comments and discussion

Docs can have comments, which keeps discussion attached to the source material. Use comments for review notes, questions, decisions, and follow-up discussion that should stay connected to the Doc.

If a discussion creates concrete work, turn that work into a task. The Doc can hold the context; Tasks can hold the execution.

Tags and organization

Tags are useful for grouping Docs across projects or topics. Examples:

  • policy

  • support

  • onboarding

  • api

  • blog-source

  • customer-facing

A clear tag habit makes Docs much easier to use later, especially when the same project contains plans, notes, instructions, and draft content.

Docs as source content

Docs can act as source material for other Aamu workflows. This blog is one example: the public blog post text comes from a Doc, while the BlogPost database row contains metadata such as slug, publish date, tags, and the linked Doc id.

That separation is useful. The Doc is where the writing happens. The database row is where structured publishing metadata lives.

The same pattern works elsewhere too: a Doc can hold a policy, a reusable support answer, a meeting agenda, or a page of product documentation while other workflows link to it.

Docs and Team Brain

Aamu Docs can be selected as Helpdesk AI knowledge sources. In that workflow, the Doc becomes part of Team Brain context that can support AI-generated ticket and email reply drafts, or Livechat AI answers when enabled.

This is one of the strongest reasons to keep Docs current. If a Doc describes pricing, support policy, setup steps, or product behavior, it can become operational knowledge rather than just static text.

When Docs are used for AI knowledge, keep them specific, up to date, and easy to cite. AI works better when the source material is clear.

Docs and AI drafts

Aamu AI can also create draft documents from workspace context. For example, a support conversation, task, email, or meeting context can become a proposed internal Doc.

The useful pattern is that AI prepares the first draft inside Aamu, where the team can review, edit, and keep it as part of the workspace.

Docs API

Aamu exposes Docs through the project-scoped API. The core endpoints are:

GET   /api/v1/docs/
POST  /api/v1/docs/
GET   /api/v1/docs/{id}
PATCH /api/v1/docs/{id}

Use the Docs API to list Docs, create a Doc, fetch a Doc with HTML content, or update the title and HTML. Authentication uses x-api-key, and project selection uses x-project-id or project_id.

When the API updates Doc HTML, Aamu updates the underlying rich-text content rather than treating the Doc as a loose markdown file. That is important when the Doc is the source of truth for other workflows.

When Docs works best

Use Docs for knowledge that should survive beyond a conversation. Use Tasks for work that needs ownership and completion. Use Databases for structured rows. Use Helpdesk and Emails for customer communication. Use Docs when the team needs a shared explanation, decision, policy, draft, or reusable context.

In Aamu, Docs is not just a document editor. It is the workspace memory that other parts of the system can read, link to, search, and build on.