Owner · Payments Team
Trust by design
Trust begins with a visible boundary.
Topoloom keeps human declarations, machine suggestions, bindings, and externally verified context distinct—across authoring, review, publication, and export.
Human-authoredDeclared ServicePayment Service
External contextObserved differenceRuntime owner differs
Suggested — not declared
Authored stateAttributed context
Knowledge-state legend
Trust has more than one axis.
Authorship, version lifecycle, and external context answer different questions. Each state uses words, a mark, and a pattern—not color alone.
Authorship
What has a person actually confirmed?
Free-form
Readable working content before formalization.
Suggested — not declared
A visible proposal awaiting authorized action.
Declared
Confirmed by an authorized person.
Version lifecycle
Which intentional version is current?
Published
An immutable, intentional version.
Superseded
Preserved history that is no longer current.
External context
What comes from a named provider?
Bound
Mapped to attributed external context.
Verified by provider
Asserted by a named provider at a stated time.
Mechanisms, not adjectives
Trust is visible in how the system behaves.
Human control
No silent mutation.
AI and connected systems can assist or suggest. They cannot decide permissions, approval, publication, or verified status.
Permissions
Access follows the knowledge.
Reads, search, references, reviews, exports, events, and external-context actions remain permission-aware.
Stable identity
Identity survives change.
Artifacts, content nodes, objects, relations, and versions remain distinguishable through their lifecycle.
Immutable versions
Publication is an explicit boundary.
Provenance, review, and audit history stay attached to the version they describe.
External context
Bindings do not prove truth.
Provider projections, evidence, and credentials remain outside authored document state.
Provider independence
Local work keeps working.
Writing, collaboration, review, history, publication, and portable export do not depend on a context provider.
Enterprise controls you can inspect
Governance is a behavior, not a badge.
The same authority boundary follows knowledge through writing, search, review, publication, integration, and movement between systems.
Tenant isolation
Workspace scope is enforced before retrieval, projection, export, event delivery, or provider access.
Permission-aware surfaces
Search results, references, graph navigation, reviews, and generated views reveal only currently authorized detail.
Immutable versions
Published versions remain addressable with provenance, review, audit, and contract context attached.
Retention and lifecycle
Archive, restore, supersession, tombstone, retention, and deletion remain explicit and auditable.
Public integration contracts
First-party and third-party consumers use the same versioned APIs, events, and permission boundary.
Portable Knowledge Package
Readable content and machine records move with explicit omissions, redactions, remappings, and permission reports.
Designed to fail safely
A dependency can fail without taking authorship with it.
External systems may enrich the workflow, but they do not decide whether local work can be written, reviewed, or preserved.
| Condition | What keeps working | What is suppressed or labeled |
|---|---|---|
| AI unavailable | Authoring, collaboration, permissions, review, publication, and export | Suggestions and generated assistance remain unavailable; no decision is fabricated |
| Context provider unavailable | Documents, diagrams, objects, history, semantic diff, and local export | External projection becomes stale or unavailable and remains outside authored state |
| Search or projection index unavailable | Authoritative PostgreSQL-backed work and immutable versions | Derived discovery views degrade and rebuild later; they never become a source of truth |
| Permission revoked | Authorized local content and non-sensitive source text | Cached projection and hidden target details disappear without an existence signal |
Non-negotiable boundaries
What Topoloom will not do.
- 01
Silently mutate authored or published knowledge through AI or an integration.
- 02
Present imported, inferred, or observed information as a human-approved declaration.
- 03
Bypass public contracts with privileged direct database integration.
- 04
Retrieve restricted knowledge first and filter permissions afterward.
- 05
Trap the customer in a rendered-only or opaque export path.
Portable knowledge
Readable by people. Inspectable by machines.
Published packages can carry readable content and versioned structure, with explicit redactions, remappings, omissions, and permission reports.
content/overview.mdReadable contentobjects/services.jsonStable IDsrelations/declared.jsonProvenancereviews/semantic.jsonChange historypermissions/report.jsonExplicit mapping
Topoloom records declarations made by authorized people.
Connected providers can report evidence or verification.
Provider context becomes authored knowledge only when a person accepts it as a declaration.
Request a demo