Evaluation guide · English
Test one Service change. Decide what comes next.
Record today’s process and what Topoloom showed, from setup to export. Note what remains unproven before widening the evaluation.
Copy before the session
Start with a blank decision record.
Copy this outline into your team’s notes before the walkthrough. Fill each line with observations and links to evidence; section 06 explains what to record.
Scope and owners: ____________________
Current baseline: ____________________
Observed workflow and evidence: ____________________
Access and data: ____________________
Failure behavior: ____________________
Export and exit: ____________________
Comparison, effort, and gaps: ____________________
Decision and next review date: ____________________01 · Problem
Choose one coordination problem.
Choose one decision about a Service that matters to your team. Record the current steps before testing whether a shared model changes the work.
Copied service descriptions
Select one concept that appears in more than one document or diagram, then document where the copies disagree or require separate maintenance.
A material change
Choose one owner, dependency, Runbook, SLO, or Decision change that a reviewer should be able to understand and approve.
A visible baseline
Record the current review time, number of copies, missing relationships, or other evidence you can measure again after the evaluation.
02 · Evaluation setup
Make the boundary explicit before the demo.
Agree what enters the evaluation, who may see it, and what would count as a useful result. Use synthetic or specifically approved content when production knowledge is not appropriate.
Dataset and import
Use one Service, one Team, two short documents, and one diagram. Add a Runbook, SLO, or Decision when relevant. Current imports accept Markdown, plain text, CSV/TSV, HTML, DOCX, and Word files exported from Confluence, up to 1 MB each. Test one file and record cleanup before planning migration.
People, access, and time
Name the author, reviewer, evaluation owner, and any read-only observer. Record their expected access, preparation work, sessions, and time commitment.
Environment and connections
Record the product version, deployment, login method, enabled features, connectors, and external services. The deployment operator currently adds workspace members; invitations and self-service sign-up are not available. Record data destinations and who can access them.
Evidence capture
Agree which screenshots, timestamps, exports, and reviewer notes support the decision. Exclude customer and production secrets.
Support and cost
Name who handles setup, questions, and incidents. Confirm evaluation charges, ongoing pricing, and included support in writing; a demo does not establish these terms.
Decision and closeout
Set a decision date and success criteria. Agree which gaps stop expansion, what may remain untested, and who owns export, retention, and deletion. Use section 06 to record whether to stop, extend, or expand.
03 · Workflow evidence
Record the result from authoring to export.
Use the Platform walkthrough to run the test. Keep the evidence below so another reviewer can assess the result without attending the session.
Authoring evidence
Keep the source document, author names, and any import cleanup notes. Identify which content stayed free-form.
Identity evidence
Record the local declaration and shared object IDs, type, author, and object version. Note whether you created an object or linked an existing one.
Reference evidence
Record the object ID and follow-current or pinned mode for each tested reference. List copies and live drafts outside the Used in result.
Review evidence
Keep the before and after version IDs, semantic diff, reviewer decision, and time needed to understand the change. Record manual corrections separately.
Publication evidence
Record the contract result, required approval, and artifact version actually published. Keep evidence that an incomplete draft can save and version creation alone does not publish.
Export evidence
Keep the package, export report, and results of opening it outside Topoloom. Section 05 lists the exit checks.
For every step, record both the successful path and the behavior when permission, provider, network, or validation conditions prevent completion.
04 · Permissions and data
Ask questions that can be answered with evidence.
The answers depend on the evaluated deployment and its configuration. Ask for demonstrations, configuration references, and named owners instead of accepting broad assurances.
Who can read, author, review, publish, export, and administer the selected resources?
Test at least one allowed action and one denied action for the roles in the evaluation matrix.
Where is authorization evaluated when content is searched, referenced, exported, or shown through an integration?
Record which checks are demonstrated and which remain design statements or configuration assumptions.
What data leaves the evaluation environment, and for what purpose?
List destinations, fields, triggers, retention, and deletion paths for each enabled integration or provider.
Which logs, analytics, backups, and support processes may contain evaluation data?
Confirm the operational owner and retention policy for the specific environment rather than assuming a global policy.
What happens when an external provider, network path, or integration is unavailable?
Observe which authoring and review tasks continue, which pause, and how incomplete or stale context is labeled.
Which security, privacy, and legal documents govern this evaluation?
Use only approved documents supplied by their owners; this guide is not a substitute for those materials.
05 · Export and exit
Test the path out before deciding to expand.
An export name is not evidence of completeness. Request an inventory of included and omitted information, then inspect the package using tools outside Topoloom.
Readable content
Confirm which document and diagram representations can be opened without a running Topoloom environment.
Structured context
Inspect whether the evaluated export includes the identities, versions, relationships, provenance, review records, and mappings required by your exit plan.
Documented omissions
List every evaluated field or behavior that is not exported, is transformed, or requires a separate administrative process.
Repeatability
Repeat the export with the same selected versions, permissions, and options. Do not expect byte-identical archives. Record any changed timestamps or external context, and explain each difference that matters for audit or downstream use.
Deletion and closeout
Agree how the evaluation workspace, provider data, accounts, backups, and evidence files are retained or removed after the evaluation.
06 · Decision record
Write down what the test established.
Complete the eight fields below in your decision record. Mark each result as demonstrated in the starting setup, demonstrated after configuration, not available, or not tested. Record any added setup, link the evidence, and name an owner for each gap.
Scope and owners
Record the Service, documents, diagram, tested change, author, reviewer, environment, and decision date.
Current baseline
Record the existing steps, repeated edits, review time, and any gaps before the Topoloom test.
Observed workflow
Record the object ID, references, second update, review result, setup effort, and manual cleanup, with evidence links.
Access and data
Record one allowed and one denied action, enabled data flows, their owners, and unresolved questions.
Failure behavior
Record the provider, permission, or validation failure tested; note what continued and what became stale or unavailable.
Export and exit
Record what opened outside Topoloom, the package format, omissions, remappings, and closeout work.
Comparison and gaps
Compare the same change with the baseline, including a second update. Give every gap an owner and resolution date.
Decision
Record stop, extend, or expand; state the evidence, assumptions still untested, and the next review date.
Next step
Test the workflow. Record the limits.
Use the glossary to align terms before the session, then request a walkthrough around the bounded workflow and evidence your team selected.