Evaluation guide · English
Evaluate one workflow. Make the evidence visible.
Use this buyer-side guide to define a bounded pilot, record what the product demonstrates, and separate verified behavior from assumptions.
01 · Problem
Choose one coordination problem.
A useful evaluation begins with a real decision that is currently slowed by copied or disconnected technical knowledge. Keep the scope narrow enough to observe before-and-after behavior.
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 pilot.
02 · Pilot 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
Use one Service, one Team, one primary document, and one diagram. Add a Runbook, SLO, or Decision only when it is relevant to the chosen workflow.
Participants
Name the author, reviewer, evaluation owner, and any read-only observer. Document the access each role is expected to have.
Environment
Record the product version, enabled configuration, integrations, identity provider, and any external service used during the evaluation.
Evidence capture
Decide which screenshots, timestamps, exports, and reviewer notes will support the final decision without containing customer or production secrets.
Exit criteria
Set a decision date and agree what must be demonstrated, what may remain untested, and which gaps would stop expansion.
03 · Sample workflow
Follow one concept from writing to exit.
Ask the product team to show each step in the agreed environment. Do not infer a capability from a slide, diagram, or term alone.
Write
Create or import a short technical explanation using the ordinary authoring surface and record what remains free-form.
Identify
Select the important concept and ask how identity, type, authorship, and current state are represented.
Reuse
Refer to that concept from a second document or diagram, then inspect whether the product created a reference or another independent copy.
Change
Propose the agreed owner, dependency, Runbook, SLO, or Decision change and observe what the reviewer can see before approval.
Publish or preserve
If the evaluated configuration supports an intentional publication or version step, demonstrate it and record what becomes immutable or remains editable.
Export and inspect
Produce the available export, open it outside the product, and compare its contents with the documented export inventory.
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 pilot 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
Run the export twice from a controlled state and explain any differences that matter to downstream use or audit.
Deletion and closeout
Agree how the pilot workspace, provider data, accounts, backups, and evidence files are retained or removed after the evaluation.
06 · Decision checklist
Close with findings, gaps, and owners.
Use the same status vocabulary for every item: demonstrated, demonstrated with configuration, not available, or not tested. A gap is actionable only when it has an owner and a decision date.
Workflow fit
The selected author and reviewer can complete the bounded workflow without creating new hidden copies or unclear handoffs.
Meaningful review
The team has evidence for what a reviewer can and cannot understand about the selected change.
Permission boundary
Allowed and denied actions were tested for the agreed roles, with unresolved cases recorded.
Data handling
Enabled data flows, operational owners, approved documents, and unanswered questions are listed.
Failure behavior
The team observed at least one relevant unavailable-provider, denied-action, or validation path.
Export and exit
The available package was inspected outside Topoloom and omissions were documented.
Measured comparison
The pilot result is compared with the baseline using evidence the decision team accepts.
Expansion decision
The team records whether to stop, extend the pilot, or expand—and names the assumptions still requiring verification.
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.