Core concepts

Understand how Organizational AI Memory organizes knowledge, reusable Assets, exact releases, and authorized delivery.

Organizational AI Memory connects two paths: evidence becomes authorized organizational Knowledge, and repeatable work becomes a governed Asset that people and agents can reuse. The paths meet when an Asset uses or pins exact Knowledge.

From sources to authorized Knowledge

1

Source

Content arrives with source identity and access evidence.

2

Knowledge Space

A governed boundary defines purpose and stewardship.

3

Knowledge Asset

A stable record points to immutable evidence versions.

4

Authorized use

Every delivery path rechecks the current actor.

Source evidence becomes versioned Knowledge without losing actor-specific access controls.

Organization and actor

An organization is the tenant boundary for people, Knowledge, Assets, configuration, and audit history. An actor is the authenticated internal identity Organizational AI Memory uses for every authorization decision. The server derives the actor from the signed-in identity; a client cannot choose a different user, organization, or department.

Knowledge Space

A Knowledge Space is one governed body of organizational knowledge. It records who the knowledge serves, who may contribute, and who administers the space. Access to a Space never overrides the permissions captured from Slack, Google Drive, GitHub, an upload, or another source.

Source and evidence

A Source is a document or object observed in an external system. Its content may change over time, so Organizational AI Memory preserves immutable source revisions and the access evidence captured with them. Original evidence remains available through authenticated citations rather than public storage links.

Knowledge Asset

A Knowledge Asset gives that evidence a stable identity while its versions remain immutable. New content can become the current version without rewriting the version that grounded an earlier result.

From repeatable work to reusable Assets

The product's Assets catalog contains four kinds of reusable capability.

Prompt template

A validated, versioned prompt with typed inputs, an output contract, data policy, optional Knowledge requirements, and evaluation cases.

Work instruction

An ordered procedure with prerequisites, expected results, checks, escalation guidance, and prohibited actions.

Capability pack

A task-ready journey that pins exact Knowledge versions and exact Asset releases in a required or optional order.

Skill

A validated package that can be released and installed for supported AI coding agents without being executed during publication.

The word Asset in the product UI refers to these four reusable types. Knowledge Asset is the technical name for governed searchable Knowledge. They are connected but do not share the same lifecycle: Knowledge follows source evidence, while reusable Assets follow owner-led authoring and exact publication.

Private working copies, sharing, and exact releases

Private working copy

Every new Asset has one human owner. The owner and explicit Editors may change the mutable working copy, but Editors cannot publish or change access.

Publish or share

The owner may publish any enabled Asset type directly. If the Asset has no release yet, its first Viewer share publishes immutable version 1.0.0 in the same database transaction as the sharing intent.

Exact release

Publication snapshots the working copy into an immutable Revision and Release with a digest and DIRECT provenance. Existing exact releases and Capability Pack pins never change when the working copy is updated.

Transfer or withdraw

Ownership can be transferred without rewriting releases; the previous owner becomes an Editor. Withdrawing the Asset blocks every release from new use and retires the stable identity while preserving authorized history.

The contributor model has two related axes rather than one linear state chain. The working copy remains mutable while publication appends immutable Releases; access is independently Private or Shared. An Editor share does not publish, while the first Viewer share does. Asset withdrawal is terminal for new use. Viewers receive released content only, and company-wide sharing is Viewer-only.

Existing reviewed releases and Deprecated availability records remain readable. The browser contribution path defaults to direct publication, shows legacy review history read-only, and hides per-release deprecation as a primary action. Compatibility review and per-release deprecation APIs remain writable; the plan closes new review mutations after compatibility rollout, while it does not currently close the deprecation API. No current organization-level policy forces review. Withdrawal prevents new consumption without rewriting release, audit, or usage evidence. Skills add one separate per-user Enabled choice: sharing controls who may discover a released Skill, while enabling controls whether that user's Assistant may select it.

Permissions, provenance, and citations

Three rules make reuse trustworthy:

  1. Permissions are checked at use time. Seeing one Space, Asset, or catalog entry never grants access to every connected component.
  2. Provenance identifies the exact version. Releases and Knowledge versions carry stable identifiers and digests so later changes cannot silently alter what was used.
  3. Citations recheck current access. A citation opens through the authenticated API, which verifies permission and evidence integrity again before returning source content.

The model does not decide authorization. Assistant, REST, graph, CLI, and MCP receive only the Knowledge or Asset release already authorized for the current actor and request.

Continue

Last updated on