Someone holding a tablet beside server racks behind glass
Products

Knowledge

A page tree with inherited permissions: application roles, directory groups, and named individuals. The same principals the door already recognises.

Inherited permissionsDirectory groups as audiencesCollaborative editingImport from existing wikis
One directoryAudiences are your existing groups, not a second membership list
InheritedThe nearest restricted ancestor governs the whole subtree
FilteredSearch returns only what the reader is entitled to see
AuditedChanges to who can read a page are recorded
01

Access is not a second directory.

The failure mode of every internal wiki is a permission model that drifts away from the organisation it describes.

Audiences are the groups your directory already maintains. When somebody moves team, their reading list moves with them, because there was never a separate membership list to update. When they leave, access ends with the account, not with a cleanup task.

Permissions inherit down the tree, and the nearest restricted ancestor wins. That single rule is what keeps a large space comprehensible: you can reason about who reads a page by looking at where it sits, rather than auditing hundreds of individual grants.

Managers curate. Everybody else sees what they are entitled to, including through the self-service portal, so a runbook and the ticket that needs it are not in different products with different logins.

Spaces
Structure
Nested page tree with spaces at the root
Audiences
Application roles, directory groups, named users
Inheritance
Nearest restricted ancestor governs
Editing
Real-time collaborative, with presence
Format
Rich text with a clean text projection
Import
Bulk import from existing wiki exports
Search
Scoped to the caller's entitlements
Audit
Audience changes recorded with the actor
02

How a page decides who may read it.

One rule, applied consistently, beats a per-page permission matrix nobody can hold in their head.

01

A space sets the default

Every space has an audience. A page created inside it is readable by that audience unless something narrower applies.

02

A page can narrow it

Restricting a page sets a new boundary. Its children inherit the narrower rule automatically, so moving a page into a restricted branch tightens it rather than leaving it exposed.

03

The nearest restriction wins

Resolution walks up the tree to the closest restricted ancestor and uses that audience. There is no additive union of grants to reason about.

04

Search obeys the same answer

Results and page previews are filtered through the identical check, so a restricted page never leaks through a snippet in a search result.

03

Who an audience can be.

Three kinds of grant, in descending order of how much maintenance they cost you.

AudienceSourceMaintenance
Directory group Synchronised from your identity platform None. It follows the organisation
Application role Baselivery roles such as administrator or agent None. It follows the role
Named individual An explicit person on an explicit page Yours to review. Use sparingly
Named grants are supported because they are occasionally necessary, and reported separately because they are what goes stale.
04

What the editor gives you.

Collaborative editing

Several people in one page at once, with live presence and no lock contention.

Self-contained

Editing works with no external service and no third-party script.

Clean text projection

Pages render to plain structured text for export and diffing.

Migration

Import an existing wiki export and keep the tree structure.

Portal reading

Entitled articles surface to end users in self-service.

Attachments

Files inherit the page's audience rather than becoming public links.

Bring the door onto the same epoch as the laptop.

We will walk you through a live portal, a compiled policy pack, and a revocation that closes the turnstile and locks the screen while you watch.