Org Knowledgebase Exchange

Push workspace learnings into a governed organization corpus and pull from it across workspaces

This artifact ships inside a Pack. For the shared lifecycle — install, pack build, upload — see Packs & Authoring SDK.

The Org Knowledgebase Exchange gives workspaces a governed path to contribute rows from their local typed data into a shared organization corpus — and to query that corpus across all workspaces at once. Think of it as a company-wide, typed, version-tracked knowledge store: past learnings, past assessments, past incidents — organized by domain, gated by review, and fully auditable.

The org KB is not a bigger workspace. Workspaces are engagement or team containers; the org KB is company IP. Promotion is the event where a row's audience scope changes from workspace-scoped to org-scoped.

Core concepts

Domains

The org KB is organized into domains (for example: learnings, compliance, support). A domain is one governed partition of the corpus — "domain" is the term used in the platform UI; "partition" is the same thing internally. Each domain is:

Typed — backed by one or more ontologies that define what object types live there.
Independently governed — its own read policy (which roles can query it), promotion policy (how many reviewers, which roles), and retention settings.
Optionally immutable — once set, an immutable domain's rows can only be revoked, never overwritten.

A domain is created when a Pack that declares knowledgebases[] is installed — there is no "create domain" action in the platform UI. See Pack manifest extension for the authoring details.

Try it: the starter Pack

The Org KB Starter Pack declares three ready-to-use domains so you can explore the exchange end-to-end without authoring a manifest first:

learnings — durable project learnings (mutable; auto-promote on validated)
contracts — executed contracts (immutable; two-reviewer promotion)
incidents — incident postmortems (auto-approved promotion)

Download the starter Pack: org-kb-starter.scrydon-pack.tar.gz (or the version-pinned build).

In the platform, go to Settings → Packs and install the downloaded .scrydon-pack.tar.gz.

Open Settings → Organization → Knowledgebase → Domains. The three domains (learnings, contracts, incidents) now appear in the table.

Promotion lifecycle

Promotion is how workspace rows enter the org corpus. Every promotion is a tracked, reviewed event — never a silent copy.

Any workspace member with the appropriate role calls org_kb.promote(), naming the target partition, the source rows, and a reason. The platform snapshots the reviewer plan (who must approve, and in which roles) at request-creation time.

Designated reviewers (drawn from the partition's promotion policy) approve or reject the request. For partitions configured with autoApproveWhen, the platform evaluates the condition on the source rows and may approve automatically.

Once the required approvals are collected the platform materializes the rows into the partition, records provenance (linking back to the originating workspace row), and — for immutable partitions — writes a signed envelope so the content is independently verifiable.

Materialized rows are immediately visible to org_kb.query() callers with read access to that partition.

Promotions can be cancelled by the initiator before any reviewer acts. The full request history (who decided, when, with what comment) is preserved in the audit log.

Querying the corpus

org_kb.query() is a federated read: the platform fans out across every partition the caller can access, applies per-partition redaction (properties classified restricted are stripped for callers without the required roles), and returns a merged, typed result set. The API supports:

asOf — point-in-time queries to see the corpus at a past timestamp.
includeVersions — return all historical versions of each row, not just the current one.
includeRevoked — include rows that have been revoked (audit / DPO scope; requires elevated privilege).

Row history and provenance

Every materialized row carries a provenance record linking it back to its source workspace row. When a row is promoted again (updated content, re-triggered), a new provenance record is created that points to the previous one — forming a version chain. You can walk the full chain with org_kb.getRowHistory().

Revocation

Org-KB rows can be revoked — removed from the standard query surface without destroying the audit trail. Revocation follows the same promotion-request lifecycle: a revoke-kind request is filed, reviewed (typically by a DPO or legal reviewer), and materialized. The revoked row disappears from org_kb.query() results but remains visible in the provenance chain for getRowHistory() and audit-bundle exports.

Re-promotion after revocation is explicitly permitted — this is how rectification works. The new promote creates a fresh row with fresh provenance; the revoked version stays in the chain as evidence.

Admin review queue

Org admins and designated reviewers manage the org KB from Settings → Organization → Knowledgebase in the platform UI, across four tabs:

Domains — lists every domain the viewer can read, with source and immutability. Each row offers Export audit bundle and Revoke a row… actions; an info affordance explains that domains are added by installing a Pack.
Review Queue — pending promotion/revoke requests across all domains; each card shows the source workspace, source rows, the reason, and the reviewer plan. Approve or reject with an optional comment.
Markings — the instance-level security marking registry: list and create markings (you can only create a marking you satisfy). See Markings & governed retrieval.
Explore — run governed query and expand retrieval as yourself, to verify access control and redaction.

The row-history viewer (launched from the Domains tab) shows the full provenance chain for any org-KB row: all versions, who promoted each, reviewer decisions, and revocation events.

Audit bundle export

org_kb.exportAuditBundle() produces a signed, self-contained archive (JSON + signatures) of all materialization events for a partition over a date range. The bundle is independently verifiable without platform access — suitable for external auditors or compliance evidence packages.