# RJL Ontology Studio · User manual

Learning and task guide · 16 October 2026 · Studio Beta

Guest tools work without an account. Optional cloud services require owner configuration and account access; integrated LLM drafting requires a funded API key and request confirmation. Drafting with your own AI assistant needs no key. See **Available in this release** under Quick reference for what is live today. Examples in this guide are synthetic working conventions, not standards or client results.

## About this builder

RJL Ontology Studio helps anyone build an ontology on any topic, such as a 5G network, retail, a clinical specialty or coffee brewing, and use it in the AI they already have. Name the topic, draft its terms with your own AI or an API key, review the draft, then export instructions and a knowledge file for ChatGPT, Claude, Gemini, Microsoft Copilot or your own application.

An **ontology** is a model of the things your domain discusses and how they relate. A **glossary** explains terms. A **taxonomy** organizes them into broader/narrower categories. Studio supports glossary and vocabulary work as well as typed connections; you can start with plain language and use technical exports later.

### A concrete example

Suppose your question is “Who owns a process, and what result should it achieve?” Your model could contain **Team**, **Process** and **Outcome**, connected as `Team → owns → Process → achieves → Outcome`. Definitions explain what those words mean within your scope. A source records why you adopted them. An evaluation question records how you checked that the model is useful.

That model does not say which employee owns today's onboarding process or whether this month's outcome was achieved. Actual assignments and results need separate authorized records. Likewise, defining a control describes its intended role; operating evidence is needed to show it works.

### Who should use it

- Anyone with a subject an AI should understand consistently: a student, a hobbyist, a specialist or a team.
- Domain experts: agree on what a term means, where it applies and who should review it.
- Engineers and data teams: connect field names to reviewed definitions and export stable identifiers and typed relationships.
- Teams with a review process: keep evidence and approvals with each definition; the tool does not determine legal applicability or compliance.

**A useful finished artifact:** a small reviewed model, an evidence reference for its definitions and connections, a recorded question assessment, an export intended for a specific recipient, and a full backup you can restore.

**Before you begin:** choose a non-sensitive example or business-meaning material you are authorized to use. A local browser is not an enterprise vault. Keep personal/customer records, credentials and regulated health/payment data outside the Studio cloud service. If a field is unclear, use the [interface glossary](#know-the-interface-and-its-language) before entering real material.

## Start from a topic

Open **New model**. Type the topic, for example *5G network*, and optionally what an AI should be able to do with it. Then choose one route:

- **Draft it with my AI.** Copy the prompt, paste it into ChatGPT, Claude, Gemini or Copilot, and paste its JSON reply back. Studio checks the reply, skips anything it cannot use, and shows what it found before you create the model. No account or key is needed in Studio.
- **Draft it with an API key.** Choose OpenAI or Anthropic, a model ID and your key. Studio sends only the topic and purpose for that one request and does not save the key. To avoid pasting it each time, let your browser or password manager remember the API key field; Studio itself never stores it. Your provider account may be charged.
- **Start blank.** Create an empty model and add terms yourself.

Every drafted term and relationship arrives as a **draft**, sourced to *Drafted from AI model knowledge* and noted as not sourced. Approve only what you have checked; attach a real source where one exists. In **Define**, use **Grow with AI** to add terms around a focus term or to find missing relationships. In **Use & export**, pick your assistant under **Use it in your AI**, copy the instructions and download the knowledge file, then use **Test it** to record whether a known question passes.

The sidebar shows the everyday tools. **Show advanced tools** reveals research collections, practice records, schema mapping, bulk editing, version comparison, knowledge health and the other specialist tools; your work is the same either way.

## Features and choosing a starting path

You do not need to use every feature. Choose the path that matches the result you need, then expand when a specific question requires it.

| Your starting point | Begin here | Result you are working toward |
| --- | --- | --- |
| You have a topic and an AI assistant | [Start from a topic](#start-from-a-topic) | A drafted model you review and use in your assistant |
| You are new to ontology work | The [first-project walkthrough](#your-first-model-a-complete-walkthrough), then Glossary | Three defined terms, two connections, one assessment and readable evidence |
| You want to inspect a complete demonstration | [Examples](#34-learn-from-a-worked-example) | A synthetic model, dictionary and assessment history to examine |
| Your practice has documents or a glossary | [Knowledge collections](#35-build-a-local-knowledge-collection) and [glossary import](#8-import-a-glossary-safely) | Selected, cited private proposals that you can review |
| You need meaning attached to field names | [Schema mapping](#33-map-a-schema-and-export-a-data-dictionary) | A reviewed CSV/JSON data dictionary, without storing record values |
| You need a client deliverable or reusable method | [Client reports](#45-prepare-a-client-ready-knowledge-report) and [practice blueprints](#44-save-and-reuse-a-practice-blueprint) | An inspectable report or an independent starting model |
| You already have a vocabulary file | [Vocabulary tools](#30-import-and-export-a-vocabulary) or [reference alignment](#48-compare-and-align-a-reference-vocabulary) | A supported subset or separate scoped mappings, with omissions visible |

### Feature map

| Capability | What it does | Availability / important boundary |
| --- | --- | --- |
| Topic start and Grow with AI | Draft terms and links for any topic with your own AI or an API key | Drafts are unsourced proposals until reviewed |
| Use it in your AI | Package instructions and a knowledge file for ChatGPT, Claude, Gemini, Copilot or an API | Files follow your selection; Studio does not sync destinations |
| Projects, templates and guided steps | Organize independent models and give a starting structure | Browser-local; template definitions are proposals |
| Definition, connection and usage review | Record terms, aliases, typed links and scoped practice usage | Review names are user-entered, not authenticated approval |
| Health, lifecycle and version tools | Identify work to revisit and retain meaningful changes | Checks support judgment; snapshots do not replace backups |
| Evaluation questions | Store expected criteria and manual assessments | Does not generate an answer or automatically score correctness |
| Schema mapping and dictionaries | Bind field metadata to selected definitions | Does not connect to a database or validate actual records |
| Collections and scoped keyword search | Extract and inspect selected TXT/MD/CSV/HTML/PDF/DOCX evidence | Collections remain local/full-backup data; OCR is not included |
| Selected public-page import | Retrieve one selected HTTPS text/HTML page | Needs the deployed Studio service; no web-wide or authenticated crawl |
| Optional LLM drafting from documents | Prepare an evidence package for manual handoff or BYOK generation | BYOK needs a funded API key, a compatible model and per-request consent |
| Practice workbench | Discuss decisions, reuse blueprints, report and align reference meaning | Local/full-backup data; six tools in the practice preview |
| Portable outputs | Produce readable evidence, AI instructions, reports and technical vocabularies | Inspect the exact draft/private/term selection before sending |
| Optional cloud and hosted snapshots | Save selected linked models or publish filtered frozen links | Invited account, hosting configuration and terms apply; collections/practice work are excluded |

**Recommended learning order:** build one small model → review and assess it → export and back it up → try a selected document → add reusable practice methods. Leave cloud accounts, LLM keys and technical formats until you have a reason to use them.

**Example:** a founder who wants agreement on “customer onboarding” can start with Glossary. A consultant with a methodology folder can first learn the same review steps, then use Knowledge research. Neither path requires beginning with RDF or an API key.

## Know the interface and its language

### Where to look

- **New model:** name a topic and start drafting. A first visit opens here.
- **My models:** create, continue, duplicate, archive or restore projects. Confirm the active project name before changing meaning.
- **Examples:** the ten-minute 5G tutorial, example topics and business demonstrations.
- **Help:** this guide.
- **Show advanced tools:** reveals Continue your work, Learning center, Quick tools, Vocabulary tools, Cloud account and the specialist project tools such as Knowledge research, Bulk edit, Schema mapping and Version comparison. On a narrow screen, choose it at the end of the **Workspace navigation** dropdown. Your choice is remembered in this browser.
- **Continue your work (advanced):** a dashboard of pending work across projects; it is not your model editor.
- **Left navigation:** choose a task inside the active project. On a narrow screen, use the **Workspace navigation** dropdown instead.
- **Guide tables on a narrow screen:** scroll wide tables sideways without moving the whole page. Keyboard users can Tab to a table and use Left/Right arrows to reveal additional columns.
- **Guided / Workbench:** choose a step-by-step sequence or direct navigation. Both edit the same project; Workbench does not grant additional privileges.
- **Breadcrumb and project name:** check where you are and which project will receive an edit.
- **Save messages:** distinguish saved browser work, chosen cloud saves and failures. Local collections and practice records still require full backups when a model is linked to cloud.
- **Dialogs:** editors open above the page. Save commits the form; Cancel/Close leaves that editor's unsaved inputs unapplied.
- **Preview panels:** inspect content or impact first. A preview is not an import, approval, download or publication until you perform the corresponding action.
- **Practice workbench tabs:** Review decisions, Practice blueprints, Client report, Question refinement, Modeling checks and Reference alignment are tools inside that one workspace.

### Words you will see

| Word / control | Plain-language meaning | Example |
| --- | --- | --- |
| Project | A separate model, scope and set of working records | Service ownership |
| Term / concept | A named meaning you want people or tools to interpret consistently | Team |
| Label | The readable name; it can change | Delivery team |
| Stable identifier / ID | The persistent local reference used by links and questions | `Team` |
| Namespace | The URL prefix for exported identifiers; not a storage folder | `https://example.org/service/` + `Team` |
| Canonical IRI | A retained full external identifier when importing vocabulary | The publisher's absolute concept URL |
| Group | A display category for organizing terms | Accountability |
| Kind of term | Type (a kind of thing), Property (a text value), Measure (a number) or Rule; exported as class, identifier, measure or policy | Team is a Type; account code is a Property |
| Alias | Another name for the same scoped meaning | Delivery unit as an alias of Team |
| Relationship / connection | A typed link with its own definition/evidence review | Team → owns → Process |
| Source | Recorded origin, version and locator for meaning | Workshop convention, section 2 |
| Collection / corpus | Selected extracted documents available for local research | An authorized practice glossary and playbook |
| Proposal / proposed | Work waiting for your review | An accepted generated definition |
| Approved / reviewed | The specified local review was recorded | A definition approved by a named reviewer |
| Separate organizational usage | Another scoped interpretation retained beside the model definition | A client's narrower use of “portfolio company” |
| Needs recheck / needs retest | Supporting meaning or recorded criteria changed | A mapped definition was edited |
| Manifest | A file describing export inventory, version and selection | Which term IDs a context package contains |
| BYOK | Bring your own funded provider API key for a confirmed request | Optional topic or evidence-backed drafting |

“Accepted” and “approved” are different stages. Accepting a research proposal adds it to the model as private, proposed meaning. Resolving a discussion records a decision, not term approval. Reviewing a schema mapping approves the binding, not the underlying term. Read the label next to each record.

**Example:** changing the label “Team” to “Delivery team” keeps ID `Team`. Relationships continue to reference `Team`. Changing its definition can require fresh connection review, question assessment and dictionary review.

## Your first model: a complete walkthrough

This exercise uses invented service-operations meaning. You need a browser and permission to save a local file; no account, original documents or API key is required. If you prefer observing a completed demonstration, use [Worked examples](#34-learn-from-a-worked-example) first.

### 1. State one question

Use “Who owns a process, and what outcome should it achieve?” We will describe the types Team, Process and Outcome, not actual employees, live assignments or measured performance.

### 2. Create an independent project

Open **My models → Create a project**. Choose **Glossary**, name it “Service ownership — learning exercise” and use `https://example.org/service/` as an exploration namespace. Choose **Create project**. The template supplies three proposed terms and two proposed connections. Open **Scope** when the Quick start screen appears.

Enter purpose “Agree on who owns a process and the outcome it supports.” Enter scope “Internal service operations; exclude individual customer records, personal assignments and live performance measures.” List the question above, then choose **Save scope**. The project name should now appear in the navigation/breadcrumb.

### 3. Inspect evidence before approval

Open **Sources & imports** and inspect **Project working definitions**. This is a working convention, not an external standard. In this exercise, use it as the explicit source of the invented definitions. For real work, add or select the appropriate authorized source and locator before approval.

### 4. Define the three meanings

Open **Define terms** and edit each term. Keep IDs unchanged. Use these example definitions and record your own name as the reviewer only after inspecting the source and scope:

| Term / ID | Modeling kind | Exercise definition |
| --- | --- | --- |
| Team | Class | A group accountable for a shared delivery responsibility. |
| Process | Class | A repeatable sequence of activities intended to achieve a defined outcome. |
| Outcome | Class | A result the process is intended to achieve. |

For each term, select the working-definition source, check **I reviewed this definition and evidence; mark approved**, then choose **Save term**. Expect three approved terms. This approval records your exercise review; it does not establish facts about an organization.

### 5. Review the connections separately

Open **Connect**. Review `Team → owns → Process` and `Process → achieves → Outcome`. The From term is on the left; the To term is on the right. Use **Relates to another type** for both, inspect their source, name the reviewer, explicitly approve and save each connection. Expect two approved connections. Term approval alone did not approve them.

### 6. Test the question

Open **Evaluation questions → Add question**. Enter the question from step 1. Expected answer / criteria: “Identify Team, Process and Outcome; cite Team owns Process and Process achieves Outcome; do not invent a personal assignment or measured result.” Select the three terms as dependencies and save.

Choose **Record assessment**. Inspect the model and enter an observed answer such as “A Team owns a Process; the Process is intended to achieve an Outcome, according to the two reviewed exercise connections.” Record a reviewer and choose Pass only if it meets your stated criteria. This is a manual exercise assessment, not a live AI test.

### 7. Inspect and download a useful output

Open **Use & export** and choose **Domain evidence**. Leave proposals and private knowledge excluded. Inspect the three definitions, two connections and source. Download the file. [Output choices](#choose-outputs-and-understand-storage) explain when to use a report, dictionary or technical vocabulary instead.

### 8. Protect it, then learn what changes

Open **Scope → Download full backup** and verify that the JSON file saved. A normal export cannot recover your complete project. If you want to practice recovery, [restore the backup](#18-protect-work-with-backups) as an independent copy.

Save a named milestone under **Version comparison**, then change one definition. Inspect pending connection reviews, the question's retest status and the before/after comparison. This is the normal maintenance loop: inspect change → review meaning → reassess the question → export a deliberate version → back up.

**Expected result:** a named project with three approved meanings, two separately approved connections, one recorded assessment, a readable evidence export and a restorable full backup. After the deliberate edit, some review/assessment work returns to pending rather than being silently accepted.

**Common mistake:** checking every approval box to finish Quick start without reading the definitions. Use the checklist to find the next activity; your review and assessment determine whether the model is useful.

## Choose outputs and understand storage

Choose the artifact for the recipient's task. A file that is useful to an AI tool or client is not necessarily a recovery file.

| Artifact | Use it for | What it does not do |
| --- | --- | --- |
| Domain evidence / AI instructions | Supply selected definitions and separate working instructions to an assistant | Does not sync the assistant, train weights or include actual operational records |
| Knowledge JSON / RDF / JSON-LD / SKOS | Exchange supported meaning with technical tools | Does not restore the full project or guarantee complete OWL interoperability |
| Schema dictionary | Explain reviewed field-to-meaning bindings | Does not validate source records or execute a database query |
| Client report, HTML or Markdown | Deliver an inspectable selected glossary, links and evidence references | Does not publish itself or certify correctness/compliance |
| Task pack | Reload a recurring selection using the latest definitions | Does not freeze a release |
| Model snapshot | Compare a frozen model with another version | Does not retain all collection and practice work for recovery |
| Practice blueprint | Start an independent project from selected methodology | Does not copy approvals or update already-created projects |
| Full backup JSON | Restore your complete local project as an independent copy | Is not a filtered client deliverable; it can contain private material |
| Hosted snapshot link | Let anyone with the link read a filtered frozen selection until expiry/revocation | Does not grant editing, name-restricted access or inclusion of private collections/practice work |

### Where work lives

| Work | Browser / full local backup | Optional linked cloud model | Normal exports / hosted links |
| --- | --- | --- | --- |
| Definitions, connections and source records | Saved | Chosen model can be saved under cloud terms | Eligibility depends on approval, privacy and selection |
| Accepted private business-meaning excerpts | Saved | Can accompany the chosen model | File inclusion is deliberate; hosted links exclude private meaning |
| Whole collections, evidence packages and saved LLM drafts | Saved | Excluded | Excluded from ordinary outputs; selected LLM packages require separate confirmation |
| Practice discussions, blueprints, reference subsets, alignments and check preferences | Saved | Excluded | Dedicated outputs require inspection; hosted links exclude them |
| Frozen question assessments and their answers | Saved | Can accompany the chosen model | Separate assessment export; client reports exclude answer text |
| API keys entered for drafting | Not saved in project/browser storage | Not saved | Excluded |

The local workspace belongs to the browser and website address you are using. Another website address, another browser and another device each have separate local storage. Use a **full backup and deliberate restore** to move complete work. Signing in alone does not upload guest work; cloud-only recovery cannot restore the local-only rows above.

**Private-excluded** is a record-selection rule, not an automatic sensitivity detector. Scope, notes, examples, public source URLs and source summaries can still contain confidential text you entered. Inspect the complete output and choose an appropriate destination every time.

**Example:** deliver a selected client report to a colleague and keep the full backup in an authorized storage location for yourself. Sending the backup instead would disclose much more working material than the report. For another device, restore that backup; importing the report would not recover the project.

For detailed steps, use [exports](#11-create-reusable-exports), [backups](#18-protect-work-with-backups), [cloud saving](#20-save-and-reopen-cloud-projects), [sharing](#22-share-a-read-only-snapshot), [blueprints](#44-save-and-reuse-a-practice-blueprint) and [client reports](#45-prepare-a-client-ready-knowledge-report).

## 1. Start here

Use **Guided** if you want a clear sequence: Scope → Define terms → Connect → Review → Use & export. Use **Workbench** if you prefer direct access to the same model and tools. Changing the viewing mode does not change your definitions.

The Studio models meaning and relationships. It helps you prepare knowledge for people and AI tools. **Knowledge research** can extract selected local documents and inspect a selected public page, then search that collection and prepare proposals for review. Optional **LLM drafting** calls OpenAI or Claude only with your API key and per-request consent, or supports manual handoff to a web account. The Studio does not search the entire web, train model weights or certify factual correctness. Definitions do not supply current operational facts.

**Your first useful result:** a small model with three clear definitions, two relationships, evidence, one evaluation question and a reusable export. Start small, review it, then expand.

1. Open **My models → Create a project**.
2. Choose **Glossary** and name it “Service operations”.
3. Keep the example namespace for exploration; choose **Create project**.
4. In **Scope**, explain your purpose, boundary and intended questions; choose **Save scope**.
5. In **Define terms**, inspect Team, Process and Outcome. They begin as proposals.
6. Review their definitions and evidence, enter a reviewer and explicitly approve each term.
7. In **Connect**, review the Team → owns → Process and Process → achieves → Outcome relationships.
8. In **Evaluation questions**, add “Who owns a process?” with an expected answer that cites the owns relationship.
9. In **Use & export**, inspect the selected knowledge and download the readable domain evidence.
10. Download a full backup before leaving. If accounts are enabled, optionally save this project to cloud.

### Worked example

**Before you try it:** Start with a new Glossary project; use synthetic working conventions.

Follow the complete first-project walkthrough near the front of this guide. At the end, return to Quick start and inspect which activities are complete and which need attention.

**Expected result:** Three definitions, two reviewed connections, one recorded assessment and a selected evidence export are available; the full backup is a separate file.

**Common mistake:** Opening a template supplies structure, but its proposals still require your review.

## 2. Understand where work is saved

Guest projects save in this browser on this website. Each website address, browser and device has its own separate browser storage. Work in one will not automatically appear in another. A browser refresh retains saved projects; clearing site data or changing devices does not.

**Saved in this browser** means the local save succeeded. A storage warning means you should download a full backup before leaving. Browser storage is not a substitute for your organization's security or retention controls.

Cloud saving is optional per project for invited users. Signing in does not upload guest projects. After accepting the cloud terms and explicitly saving a project, changes to that linked project save while you are signed in. Full cloud projects include private accepted glossary passages and history. Hosted sharing uses a separate, filtered snapshot.

Invited cloud accounts have no automatic expiry. Chosen cloud projects remain until you or an administrator delete them, or the service ends with notice. Share links retain their own expiry. Keep independent backups: local browser copies and downloaded backups remain your responsibility. Removing the former 90-day limit does not recover previously deleted work.

### Worked example

**Before you try it:** Use a synthetic project you can recognize by name.

Create “Local learning project”, refresh the page and reopen it from My models. Then open Studio in a different browser: the original project will not automatically appear there. Move it by full backup and restore if needed.

**Expected result:** The same origin/browser retains saved work after refresh. A different origin starts with a separate local workspace.

**Common mistake:** A cloud-saved model does not include whole collections or practice records. Keep a full local backup for complete recovery.

## 3. Create and manage projects

Choose **New model** to start from a topic (see [Start from a topic](#start-from-a-topic)), or **My models → Create a project**, or **Use template** under a starting pattern. Starting patterns are grouped by the kind of model:

- **Starter · Blank model:** your own domain and terms.
- **Glossary:** Team, Process and Outcome as editable proposals.
- **Taxonomy:** Category, Subcategory and Item, with an "is a kind of" link.
- **Domain ontology:** Actor, Resource, Event and Location, with a name and a quantity.
- **Process:** Process, Step, Role, Input and Output.
- **Example · 5G network, Coffee brewing, Library catalog:** finished teaching models outside business.
- **Example · Retail:** sourced retail proposals, a sample calculator and a retail comparison workflow.
- **Example · business patterns:** AI & data capabilities, Service operations, Consulting engagement, Policy & accountability, Project delivery and Data governance.

Filter starting patterns by category or search for a term. Choose **Preview template** to inspect its purpose, proposed terms, relationships and evaluation questions before creating it. Adapt all proposals to your own evidence.

Templates create independent projects. Editing one does not change another. Choose a descriptive name of up to 120 characters. A namespace identifies exported concepts. It is optional: Studio makes one from the project name, and you can change it under **Advanced** or in Scope. Use an HTTP(S) URL ending in `/` or `#`. For example, `https://example.org/service/` plus the stable identifier `Team` identifies that term. Use a namespace you control when publishing.

Choose **Continue** to open a project. Choose **Manage** for a full backup, **Duplicate project**, or **Archive project**. Archiving hides a project from the active list and preserves its contents. Use **Show archive → Manage → Reopen project** to return it. Duplicates have new IDs and no account link.

### Worked example

**Before you try it:** Choose one bounded purpose, such as service ownership.

Create two Glossary projects named “Service ownership A” and “Service ownership B”. Change Team in A, then open B. Archive B from its Manage dialog and reopen it through Show archive.

**Expected result:** A and B have independent content. Archiving preserves B and removes it from the active list.

**Common mistake:** A duplicate keeps its working content but has a new project identity and no cloud link; review its scope and intended destination.

## 4. Set the purpose and boundary

Open **Scope**. Complete the project name, purpose, scope, questions and namespace, then choose **Save scope**.

A useful purpose describes a decision or task: “Agree on who owns service processes and which outcomes they support.” A useful scope states what belongs and what does not: “Internal service delivery; exclude supplier contracts and financial metrics.” List a few questions the model should help answer.

Scope questions are planning notes. **Evaluation questions** add separate acceptance criteria and recorded assessments. Updating scope changes the model version and can require retesting earlier assessments.

### Worked example

**Before you try it:** Open the learning exercise project.

Enter purpose “Explain process ownership”, scope “Internal service delivery; exclude personal assignments” and question “Who owns a process?” Save scope, then inspect the project title and version.

**Expected result:** The saved purpose and boundary guide the model. The free-text scope question is a planning note; add an Evaluation question to record criteria and a test.

**Common mistake:** Entering a question in Scope does not create an assessed Evaluation question.

## 5. Define clear terms

Open **Define terms → Add term**. Enter a label, stable identifier, group, kind of term (Type, Property, Measure or Rule), definition and source reference. **Grow with AI** on this page drafts more terms around a focus term, or missing relationships, with your own AI. Add aliases, an example and scope notes where useful.

Use stable identifiers such as `ServiceTeam`: start with a letter and use letters, numbers, underscores or hyphens. The label can be readable, such as “Service team”. Existing IDs cannot be renamed. To replace an ID, add a new term deliberately and update its connections and evaluation questions.

- **Class:** a type of thing, such as Team or Process.
- **Policy:** a type of rule, such as an escalation policy.
- **Identifier:** a text property, such as an account code.
- **Measure:** a numeric property, such as elapsed hours. Its definition does not execute a calculation.

Write definitions that distinguish neighboring concepts. Example: “A service team is a group accountable for delivering a defined service outcome.” An alias is another name for the same scoped meaning, not a competing definition.

Choose **Save term** to keep a proposal. To approve it, enter a reviewer and check **I reviewed this definition and evidence; mark approved**. Every save requires a fresh review decision. A meaningful term change returns affected relationships to review.

Use the search box and group filter to find terms. **Table** shows detail, **Graph** shows connections, and **Hierarchy** shows type-of structure. Select a term to inspect its evidence and relationships. Graph nodes can be activated with Enter or Space.

### Worked example

**Before you try it:** Keep a stable ID and select a known source.

Edit Team: label “Delivery team”, ID `Team`, Class, definition “A group accountable for a shared delivery responsibility.” Add alias “Delivery unit” and an example describing a type of team. Save as a proposal; inspect it again before approving with a reviewer.

**Expected result:** The visible label changes while ID `Team` remains. Approval is recorded only when the explicit review box and reviewer are supplied.

**Common mistake:** An alias is another name for the same scoped meaning. Use separate organizational usage for a competing definition.

## 6. Connect the model

Add at least two terms. Open **Connect** or use **Add a connection** from a term's details. Enter a stable relationship identifier, From term, kind, connection label, To term and source reference.

- **Relates to another type** (object relationship): links things, such as Team → owns → Process.
- **Has a property or measure** (datatype relationship): links a thing to a Property or a Measure.
- **Is a kind of (hierarchy):** links a more specific Type or Rule to a broader one.
- **SKOS — has broader term:** links a vocabulary concept to its broader category.
- **SKOS — is related to:** records an associative vocabulary connection.

Example: SupportTeam → is a kind of → Team. The direction goes from the specific type to the general type. Cycles in this hierarchy are rejected. Choose distinct endpoints and compatible modeling kinds.

Review the evidence, enter a reviewer and explicitly approve the relationship when ready. Deleting a term also removes its connected relationships after confirmation. **Scope → Undo last change** can reverse a recent change during the current session; up to 20 changes are retained. Undo is not a persistent recovery system.

### Worked example

**Before you try it:** Have Team and Process in the model as class-like terms.

Review `Team → owns → Process`: From Team, **Relates to another type**, label owns, To Process, and the working-definition source. Inspect and approve that connection separately. For a type hierarchy, add a SupportTeam class and connect it to Team with Is a type of.

**Expected result:** The object connection links two types; the hierarchy points from the specific type to the general type.

**Common mistake:** Reversing From/To changes the assertion. A SKOS broader link organizes vocabulary and does not automatically assert OWL subclass membership.

## 7. Add evidence and source dates

Open **Sources & imports → Add source**. Enter a title and kind: External reference, Project convention or Private document. Add a source URL where appropriate, version/effective date, **Source reviewed on**, a page/section/passage locator and authority/scope notes.

Distinguish the publication/effective date from the date you checked it. “Version 3, effective 2025-04-01” and “reviewed on 2026-10-11” answer different questions. A locator should help another person find the passage behind a definition.

Sources attach evidence metadata; entering a URL in the source editor does not fetch the page. Use **Knowledge research** for PDF/DOCX text extraction or selected public-page imports. The glossary importer accepts glossary text and CSV. Keep proprietary passages in private source kinds and review sharing fields before publication.

Changing a source returns its dependent definitions, relationships and organizational usage to review. Imported sources remain private; the source editor does not silently turn them into public references.

### Worked example

**Before you try it:** Decide whether the source is an external reference, private document or a declared convention.

Add a Project convention titled “Synthetic service workshop”, version “Exercise v1”, locator “Definitions, section 2”, and a brief authority note that it is an invented convention. Select it for the relevant definition, then review that definition again.

**Expected result:** A reviewer can identify the origin and location of the meaning. A source edit makes dependent work need review.

**Common mistake:** A source URL is a reference until you deliberately retrieve a selected page in Knowledge research.

## 8. Import a glossary safely

Open **Sources & imports**. Paste TXT/Markdown glossary lines, or choose a supported glossary file. Give the import a meaningful source title. Supported files are CSV, TXT and Markdown.

For pasted text, put one proposed entry on each line:

```text
ServiceTeam: A group accountable for delivering a defined service outcome.
ServiceProcess: A repeatable set of activities that delivers that outcome.
```

Choose the text preview action, inspect the candidates, select only the entries you want and accept them. Changing the input requires a fresh preview. Nothing is approved automatically.

For CSV, use a header row and map the term and definition columns. Optional aliases use semicolons; group is optional. Quoted definitions can contain commas and line breaks.

```csv
term,definition,aliases,group
ServiceTeam,A group accountable for a service outcome.,Service unit;Delivery team,Operations
```

The import preserves existing model definitions. If an imported term matches an existing term, its new passage becomes separate organizational usage for review. Only accepted candidates enter the project. An entirely unselected passage is not stored in its full backup.

Import text is limited to 200,000 characters. The file chooser also rejects glossary files over 1 MB. Split large glossaries into useful domain sections.

### Worked example

**Before you try it:** Use only glossary entries you may retain as private meaning.

Paste `ServiceTeam: A group accountable for a defined service outcome.` with source title “Synthetic glossary”. Preview it, select that entry and accept it. If you also import a differing Team definition, inspect the separate organizational-usage proposal.

**Expected result:** The selected new entry appears as private proposed meaning; the original Team definition remains intact when a difference becomes separate usage.

**Common mistake:** Import acceptance does not approve the term, and private imported terms are excluded from default exports even after approval.

## 9. Review proposals and organizational usage

Open **Review** to inspect pending definitions, connections and imported usage. Follow the edit/review action, compare the meaning and evidence, enter a reviewer and make an explicit decision.

An organizational usage is a separate local interpretation. Choose **Keep as reviewed usage** if it is useful within its stated scope, or **Discard usage**. Keeping it does not overwrite the model definition. Pending usage is excluded from exports. Reviewed private usage enters file exports only when you explicitly include private knowledge; it never enters hosted read-only links.

Reviewer names are user-entered records. An account login does not convert these into authenticated approvals or independent certification.

### Worked example

**Before you try it:** Have a proposed term or a pending organizational usage.

Import a synthetic narrower Team usage, open Review and compare it with the model definition. Keep it as reviewed usage only if both the distinction and scope are useful; record the reviewer.

**Expected result:** The canonical/local model definition and the separate usage remain distinguishable. Pending usage stays out of exports.

**Common mistake:** Resolving a Practice workbench discussion does not approve the definition in this Review workflow.

## 10. Use knowledge health

Open **Knowledge health**. Review the counts for Structural errors, Review warnings and Useful next steps. Use **Show** to filter findings, then **Inspect** to open the relevant editor or workflow.

Checks identify ambiguous labels/aliases, short definitions, differing organizational usage, review gaps, unconnected terms, missing locators, missing source dates, source dates more than 180 days old and incomplete scope. A difference in usage may be legitimate; investigate its context before changing the definition.

An old source date is a prompt to check applicability. It does not prove the source is obsolete. After checking it, record **Source reviewed on**. Structural consistency and a clean dashboard do not establish factual truth.

### Worked example

**Before you try it:** Open a project with a deliberately ambiguous alias or missing locator.

Give two differently scoped terms the alias “Owner”, then inspect Knowledge health. Use Inspect to compare them and either clarify their labels/scope or remove the ambiguous alias. Add the missing locator to its source.

**Expected result:** The corresponding finding disappears when the underlying issue is repaired; other findings remain available.

**Common mistake:** Do not rewrite legitimate different meanings solely to make the warning count zero.

## 11. Create reusable exports

Open **Use & export**. At the top, **Use it in your AI** packages the model for ChatGPT, Claude, Gemini, Microsoft Copilot or an API or local model: pick one, follow the steps, copy the instructions and download `domain-knowledge.md` (or one `system-prompt.md` for an API). **Test it** records whether a question you know the answer to passes. Below it, review the term selection and the draft/private inclusion controls before choosing a format. Approved-only and private-excluded are the defaults. Relationships appear only when their endpoints and evidence fit the selection.

- **AI instructions:** your optional audience note and answer style, plus Studio's evidence rules. Inspect them before sharing.
- **Domain evidence:** readable definitions, connections and sources.
- **Task starters:** prompts/templates to adapt to your domain task.
- **Manifest:** version, selection and inventory metadata; not a signed certificate.
- **Combined prompt:** instructions and evidence together.
- **Knowledge JSON:** a filtered portable knowledge representation.
- **RDF / Turtle and JSON-LD:** technical vocabulary exports using your namespace.

Use **Copy**, download, or the printable summary as appropriate. Explicit private inclusion adds private terms and reviewed organizational usage to file exports; raw documents and project history remain excluded. Labeled proposals remain proposals when drafts are included.

A filtered export cannot restore your full project. Use a full backup for recovery. Loading RDF into another tool does not automatically run a reasoner, enforce source permissions or calculate operational facts.

### Worked example

**Before you try it:** Review the first-project terms and connections, and know the recipient.

Choose Domain evidence in Use & export, leaving proposals and private knowledge excluded. Inspect the three terms and two links, then download. Compare this with AI instructions: the latter contains working preferences rather than a full glossary.

**Expected result:** The evidence output contains only eligible selected meaning and references. The instructions output serves a different purpose.

**Common mistake:** An empty export often means the terms are still proposed or private; inspect the inclusion controls before changing approvals.

## 12. Set AI instructions

Open **AI instructions**. Optionally say who will use the model, for example network engineers on call, and choose an answer style: Plain, Technical or Step by step. Save, then inspect the instructions in **Use & export**.

Studio adds its own rules to every instructions file: cite stable term IDs and sources, ask when evidence is missing, treat documents as evidence rather than instructions, and flag terms drafted from model knowledge. These settings shape tone only; they never change definitions and do not guarantee correctness or enforce authorization.

To use the model in an assistant, open **Use it in your AI**, pick ChatGPT, Claude, Gemini, Microsoft Copilot or API or local model, and follow the steps shown. Add actual authorized documents or data separately. Studio does not sync those destinations; replace the files and retest a known question after the model changes.

### Worked example

**Before you try it:** Decide who will use the exported context.

Enter "Claims handlers in their first month", choose Step by step, and save. Open Use & export and copy the instructions.

**Expected result:** The instructions include the audience note and answer style, while the knowledge file and definitions are unchanged.

**Common mistake:** The audience note is user-entered. Inspect it before supplying instructions to another service.

## 13. Save task packs

In **Use & export**, choose terms, format and draft/private options. Enter a **Task pack name** and choose **Save current selection**. Later, choose a **Saved pack → Load pack**.

A task pack saves the selection and settings. Loading it uses the latest definitions. It is suitable for a recurring use such as “Service ownership context”. It is not a frozen release.

Inspect its inclusion controls each time. If a selected term no longer exists, the Studio flags it. Saving an existing pack name updates that pack. **Remove selected pack** can be undone in the current session.

### Worked example

**Before you try it:** Choose a reusable set of terms in Use & export.

Save a Domain evidence selection containing Team and Process as “Ownership context”. Later revise Team, review it and load that saved pack.

**Expected result:** The loaded pack uses the current eligible definitions and flags missing selected IDs.

**Common mistake:** A task pack stores a selection, not the old definitions. Use a model snapshot to preserve a model milestone.

## 14. Capture and compare versions

Open **Version comparison**. Enter a **Snapshot name**, such as “Ownership review complete”, and choose **Save current snapshot** before making model changes.

Choose **Compare from** and **Compare to**, then **Compare**. Review added/removed terms and relationships, changed fields, sources and scope. Expand a changed item to inspect Before and After.

Snapshots are frozen model content, including private definitions and source metadata. Saving one does not change the model version. Download **model JSON** for inspection; a model snapshot is not a full project backup. Full backups include snapshots. The initial project limit is 30 snapshots.

### Worked example

**Before you try it:** Save a meaningful milestone before editing.

Save snapshot “Ownership agreed”, revise the Process definition, then compare that snapshot with Current model. Expand the changed record to inspect Before and After.

**Expected result:** The saved baseline stays unchanged and the comparison identifies the edited fields.

**Common mistake:** The downloaded model snapshot is an inspection artifact, not a full project recovery file.

## 15. Evaluate questions in any domain

Open **Evaluation questions → Add question**. Enter the question, **Expected answer / acceptance criteria**, and optional supporting terms, then **Save question**.

Example question: “Who owns a process?” Expected: “A team owns the process; cite Team, Process and the owns relationship.” Select Team and Process as dependencies.

1. Choose **Record assessment**.
2. Enter the actual answer or evidence observed. You can record an answer from a human or an external tool.
3. Enter a reviewer.
4. Explicitly choose Pass, Partial or Fail and explain missing evidence in notes.
5. Choose **Record assessment** to save the frozen question, criteria, model and version.
6. Inspect the latest assessment and history; download the frozen record when useful.

Evaluation questions record manual assessments; they do not call an AI model or infer a score. A question with no assessment is untested. Model/version or question/criteria changes flag recorded assessments for retesting, and stale passes are excluded from **Current assessments passed**. A removed supporting term must be repaired in the question before a new assessment can be recorded.

The project supports 100 questions and 200 assessments. Full backups retain both. These user-entered results are evidence of your review activity, not measured claims of AI improvement.

### Worked example

**Before you try it:** Have a question and explicit criteria before recording a result.

Ask “Who owns a process?” Expected criteria: identify Team and Process and cite owns. Record the answer you actually inspected; mark Partial if it names Team without supporting evidence. Improve the model or answer and record a new assessment.

**Expected result:** The assessment history retains your entries. Current pass counts exclude stale passes after criteria or model changes.

**Common mistake:** Pass is a user-entered judgment, not an automatic test of an AI model or factual certification.

## 16. Use quick tools without a project

Open **Quick tools** (shown with **Show advanced tools**). Select the input format, paste a glossary and choose a conversion namespace. Choose **Check glossary** to inspect duplicate terms, conflicting aliases and short definitions.

Download CSV, Markdown, Knowledge JSON, RDF/Turtle or JSON-LD, or choose **Continue in a project**. Converted terms are proposals. RDF quick conversion treats them as classes; refine modeling kinds in a project. Changing input clears earlier results until you check again.

Quick tools run locally. Downloading a conversion does not create a saved project unless you choose to continue editing in one.

### Worked example

**Before you try it:** Use a short synthetic glossary; no saved project is required.

Choose text input and paste two Term: definition lines. Check glossary and download Markdown. Choose Continue in a project only when you want to edit and review the result.

**Expected result:** A conversion file is available without creating a project; continuing creates proposed terms for review.

**Common mistake:** RDF quick conversion initially treats terms as classes. Refine kinds after continuing into a project.

## 17. Find definitions

Open **Find definitions**, enter a term or alias and run the lookup. Inspect the definition, status and source. This is deterministic lookup over the current project; it is not live AI search or a web search.

For broader exploration, use the search box under **Define terms** with table, graph or hierarchy views.

### Worked example

**Before you try it:** Open the project containing the meaning you want.

Look up “Team” or a retained alias such as “Delivery unit” in Find definitions. Compare the result with a search for an unrelated word.

**Expected result:** A known label/alias retrieves current model meaning and sources; an unrelated word provides no matching definition.

**Common mistake:** This lookup does not search your full document collection or the web. Use Knowledge research for corpus passages.

## 18. Protect work with backups

Choose **Download full backup** from Scope, or **My models → Manage**. Keep the JSON file somewhere appropriate for its contents. Full backups include private accepted passages, proposals, history, preferences, task packs, snapshots and evaluations.

To restore, open **My models → Restore backup** and choose the file. Restoration validates the data and creates an independent project with a new ID. It never replaces the active project or relinks it to an account. The limit is 5 MB.

A filtered export, model snapshot or assessment download cannot be used as a full backup. Back up before clearing site data, moving to another browser or address, switching browser/device or resolving a storage warning. Signing out does not delete local copies from a shared device.

### Worked example

**Before you try it:** Use a non-sensitive test project and a permitted file location.

Download a full backup, verify the JSON file saved, then use My models → Restore backup. Open the restored project and inspect its definitions and any collection/practice records.

**Expected result:** Restoration creates a new project identity with preserved working content and no inherited cloud link.

**Common mistake:** Choosing a report, dictionary or filtered Knowledge JSON file in Restore backup does not recover the project.

## 19. Accept an invitation and cloud terms

Open **Cloud account**. If the service is not enabled, guest mode and file exports remain available. Netlify dashboard/team authentication is separate from a Studio application account.

Accounts are invitation-only for participants in RJL Solutions workshops that use the Studio. There is no public account-registration option. Open the invitation from your email, enter a new password of at least 12 characters personally, and choose **Save password & sign in**. For later sign-ins, enter your email and password under **Cloud account → Sign in**. Do not put passwords or email-action links in project data or chat.

Before the first cloud save, review **Before your first cloud save** and open **Studio cloud terms**. If you agree, check the acceptance box and choose **Accept and continue**. If the terms page is unavailable, keep using guest mode and contact the owner; do not accept unread terms.

Cloud use is limited to business meaning: terms, definitions, relationships, examples and document references. Do not store personal data about customers or employees, customer records, credentials, or regulated health/payment data. The service uses US-region Netlify storage, operated by RJL Solutions; the operator can technically access saved projects. A private project is not a vault for prohibited data.

Choose **Send recovery link** to request a password reset. If your confirmation, invitation or recovery email opens a different Studio version, expand **Finish an account email link** in the version you want to use. Paste your own link and choose **Continue with email link**. Confirmation completes the account; invitations and recovery ask you to enter a new password. The app extracts recognized Studio tokens and clears the field.

Account setup and recovery require HTTPS. Availability depends on owner configuration and completed live account acceptance for the deployment you are using. Account access is for your private projects; there is no team editing or role-based review workflow in this release.

### Worked example

**Before you try it:** You need an actual Studio invitation and readable current cloud terms.

Open your invitation personally, complete its password step and sign into Cloud account. Read the linked cloud terms and permitted-data scope before deciding whether to accept. If no invitation is available, continue the learning exercise locally.

**Expected result:** An enabled invited account can choose model saves. Guest work remains usable without this setup.

**Common mistake:** Signing into Netlify administration is separate from signing into the Studio application; never paste credentials into project fields.

## 20. Save and reopen cloud projects

Open the local project you want to save, then **Cloud account**. Accept the current terms first, if prompted, then choose **Save this project to cloud**. Review the notice: this includes the chosen project's private accepted passages, preferences, snapshots and assessments. Other guest projects are not uploaded. Keep the content within the permitted business-meaning scope.

While signed in, later changes to that linked project save automatically. Look for **Cloud saved**, **Cloud changes pending**, or an error/conflict message. Preserve a backup when a save fails. The initial limits are 4 MB per cloud project and 100 cloud projects per account.

On another device or browser, sign in under **Cloud account**, choose **Refresh list** if needed, then **Open cloud copy**. With no matching local ID, it opens as a linked project. If this browser already has that ID, the Studio creates a separate local cloud copy to preserve existing work. Duplicate copies are unlinked until you deliberately save them.

You can choose **Download cloud backup** without replacing a local project. **Sign out** ends this browser's account session and retains its local projects. A project linked to a different account must be duplicated before saving it to your current account.

To remove one saved copy, choose **Delete cloud copy** from the cloud project's card, read the confirmation, and confirm the deletion only if intended. This permanently deletes that cloud copy and its hosted links; the local browser project remains. Download a backup first if you want to keep a recoverable copy.

To end your cloud access and delete all its data, expand **Delete all of my cloud data**, read the notice, type **DELETE** and choose **Delete all my cloud data**. All cloud projects and links are permanently removed and you are signed out. Local projects remain. Access remains ended after signing in again; contact RJL Solutions if you later need access again.

### Worked example

**Before you try it:** Sign in to the account that should own this model; keep a full local backup.

Choose one synthetic project and Save this project to cloud. Wait for Cloud saved, make a small permitted change and inspect the new status. Open its cloud copy separately where a local matching ID already exists.

**Expected result:** The selected linked model saves; the original local copy remains when a separate cloud copy opens.

**Common mistake:** A cloud-only copy has no whole research collection or Practice workbench records. Restore a full backup for those.

## 21. Resolve a cloud conflict

A conflict means another device saved a newer cloud revision. The Studio stops updating that cloud project and preserves your local work. Editing again does not silently clear the conflict.

1. Download a full backup of your local version, then open **Cloud account → Refresh list**.
2. On the card for the active linked project, choose **Compare local & cloud**. Sign in to the account that owns this link.
3. Expand each row's **Local content** and **Cloud content**. Each difference initially keeps the local copy. Choose **Cloud copy** where you want its value. Choosing an absent record removes that record from the result.
4. Review dependencies together: removing a term also requires removing its connections; sources must remain available for the terms and links that cite them. Invalid combinations are rejected without changing the project.
5. Confirm your reviewed choices and choose **Preserve copies and apply choices**. Two independent browser projects preserve the original local and cloud copies. The combined project retains its cloud link and saves against the fetched cloud revision.
6. Changed meaning or evidence returns affected definitions and connections to proposed. Recheck the evaluation questions and export the new version after review.

Comparison pauses automatic cloud saves for this project while you review it. Editing the project makes the comparison stale; choose **Refresh comparison** before applying. Choose **Cancel comparison** to return without applying choices. Opening a different project also cancels the comparison. If another device saves again, the server refuses replacement; your combined local work and both originals remain available. Start a fresh comparison. Browser copies count toward the 100-project local limit and contain private material. Download their full backups for durable recovery.

You can still **Open cloud copy** separately or **Download cloud backup** without combining anything. The comparison is a manual choice of records and project fields; it does not infer which meaning is correct or automatically merge edits inside a definition.

If another tab changes the local workspace, back up the current session and reload. Local writes and new cloud saves pause to prevent the older tab from overwriting newer work. An upload already in flight can finish; conditional cloud revisions still apply.

### Worked example

**Before you try it:** Use two deliberately different synthetic copies and download a local backup first.

When a real revision conflict occurs, compare local and cloud definitions. Keep Local content for your intended scope and choose Cloud copy only for records you inspected. Review dependent source/relationship choices before applying.

**Expected result:** Two safety copies preserve originals, and the chosen combination saves only against the fetched revision.

**Common mistake:** Choosing a cloud term without its needed source, or removing an endpoint while keeping its connection, can make the result invalid.

## 22. Share a read-only snapshot

Sign in and open **Share snapshot**. Choose the current model or a saved snapshot, and an expiry of 1, 7, 30 or 90 days. The term selection comes from **Use & export**. Include labeled drafts only if intended.

Inspect **Exactly what recipients will see** and **Inspect complete shared content**. Hosted links always exclude private imported definitions, organizational usage, personas, reviewer names, raw documents and assessment answers/history. Review selected public notes, examples and source URLs for sensitive content yourself.

Check **I reviewed the preview and want anyone with the link to read this selection**, then choose **Create expiring link**. The Studio saves the selected project privately first and filters it again on the server. A conflict or failed save blocks creation.

Copy and keep the new link; it is shown only when created. Anyone who has it can read, print or download the frozen selection. It is not restricted to named recipients. Later project edits do not change that snapshot. Recipients get no editing access.

Under **Links for this project**, choose **Revoke link** to stop future access. Expired/revoked links no longer return the snapshot. Printed/downloaded recipient copies cannot be recalled. Deleting the source cloud project or ending the account's access also removes its hosted links; keep independent backups. A link has its own expiry even though accounts do not expire automatically. The initial account limit is 100 share records, including revoked/expired records.

### Worked example

**Before you try it:** You need an enabled invited account, eligible reviewed public meaning and permission to share.

Select Team and Process, choose a one-day expiry and inspect the recipient preview. Create the link and open it. Later revoke it and confirm that new access stops.

**Expected result:** The link contains a frozen filtered model, not an editor. Later local edits do not change it.

**Common mistake:** Anyone with the link can read it until expiry/revocation; downloaded recipient copies cannot be recalled.

## 23. Explore the optional retail example

Retail projects include **Retail calculator** and **Retail comparison**. Other templates use the general evaluation-question workflow.

The sample calculator uses fixed example formulas over six synthetic order lines: gross sales 195, net sales 160, units ordered 10 and distinct orders 5. Refunds follow original order dates; tax and shipping are excluded. Definition edits never change those formulas. Actual data must use a single currency and match the supplied CSV conventions.

The retail comparison records manually entered baseline/context answers and explicit criteria. It does not run a model or independently verify results. Keep dataset, model settings and task inputs consistent when conducting your own comparison.

### Worked example

**Before you try it:** Open a Retail example and use the bundled synthetic sample.

Load the sample data in Retail calculator and inspect gross/net totals. Then edit a glossary definition and calculate the same sample again.

**Expected result:** The fixed sample conventions still produce gross 195 and net 160; a definition edit does not rewrite calculation code.

**Common mistake:** Do not treat the synthetic totals or manually entered Retail comparison results as measurements of your own business.

## 24. Troubleshooting

- **My project is missing in another browser or address:** each has separate storage. Download a full backup where the project lives and restore it where you need it.
- **My export is empty:** proposals and private evidence are excluded by default. Review terms, adjust the selection, or explicitly include labeled drafts where appropriate.
- **A relationship is missing from export:** check endpoint selection, approval status, source kind and modeling compatibility.
- **No account form appears:** the owner has not enabled Identity, or the account service is unavailable. Continue locally and keep backups.
- **Sign-in fails after registration:** confirm the email first; check credentials, invitation-only registration and recovery.
- **Cloud save failed or remains pending:** check connectivity and account status, preserve a backup and retry. A revision conflict requires the reviewed local/cloud comparison or separate-copy workflow.
- **Saving asks for cloud terms:** read the linked terms and accept them only if you agree. Saves and shares remain blocked until the current terms are accepted.
- **Cloud access has ended:** cloud copies and links are deleted. Local projects and existing backups remain. Contact RJL Solutions about an extension; signing in again does not start a new term.
- **An older tab cannot save:** back it up and reload. Do not keep editing multiple tabs against the same browser workspace.
- **A question says Retest after changes:** record a fresh assessment against the current model and criteria. Earlier history remains intact.
- **A source still shows an age warning:** inspect its effective/reviewed date and record a recent review after checking applicability.
- **A shared link is unavailable:** it may be expired, revoked, copied incorrectly, or opened on a different Studio address. Ask its creator for a new link.
- **Clipboard fails:** download the export or copy from the displayed link field.
- **Restore rejects a file:** use a full Studio backup under 5 MB. Filtered exports and model snapshots are different formats.
- **Import rejects CSV:** verify headers, column mapping, quoted commas/newlines and equal column counts. Split an oversized glossary.

### Worked example

**Before you try it:** Identify the message and the action that preceded it.

If Domain evidence is empty, inspect whether terms are proposed, private or excluded by selection. Approve only after review; include labeled private/proposed material deliberately if that is the intended output. If work is missing on another website address, use full-backup restore.

**Expected result:** The chosen remedy addresses the underlying selection or storage boundary instead of discarding work.

**Common mistake:** Clearing browser data as a troubleshooting step can remove local collections and practice work. Back up first.

## 25. A useful return routine

When you return, open the project, inspect **Knowledge health**, review changed sources, update definitions, compare with a milestone snapshot and retest your evaluation questions. Load the relevant saved task pack and export the current knowledge. Refresh shared snapshots deliberately when recipients need a new version, then download a full backup.

Keep a small set of questions that reveal whether the model is useful. Clear definitions, traceable evidence and reproducible assessments give you a reason to return as your knowledge changes.

### Worked example

**Before you try it:** Return to a saved project with a known question and milestone.

Inspect pending work, check a changed source, review affected meaning and rerun the question assessment. Compare with the milestone, load the intended task pack and download a new export and full backup.

**Expected result:** The new deliverable has a deliberate version and current review records; earlier milestones remain available.

**Common mistake:** An old exported context file will not update itself when you return and edit the model.

## 26. Quick reference and limits

- Guided/Workbench: two views of the same project.
- Approved/proposed: user-entered review decisions, not independent certification.
- Task pack: saved selection that uses current definitions.
- Model snapshot: frozen terms, relationships, sources and scope.
- Full backup: private recovery file with complete project history and preferences.
- Hosted link: frozen, filtered selection readable by anyone who has the link.
- Initial limits: 100 browser projects; 50 task packs, 30 snapshots, 100 questions and 200 assessments per project; 100 cloud projects and 100 share records per account.
- File limits: 200,000 glossary characters; 1 MB glossary file; 4 MB cloud project; 5 MB backup restoration.

### Available in this release

Reviewed 23 October 2026.

- **Open to everyone, no account:** guided and workbench modeling, reviews, evaluation questions, exports, task packs, snapshots, backups, quick tools, local knowledge collections and research proposals, the learning center and the optional retail example.
- **Use your own AI assistant:** download or copy the instructions and knowledge files and use them in ChatGPT, Claude, Gemini or Copilot. No key is needed.
- **By invitation:** cloud saving and expiring read-only share links, where accounts are enabled for the Studio you are using.
- **With your own API key, Beta:** integrated OpenAI or Claude drafting, one confirmed request at a time. Keys entered for a request are not saved.
- **Not available:** web-wide search, database connectors, authenticated enterprise approval workflows, publishing to GitHub or a catalog, and a formal ontology reasoner.

See the integration guide for AI context examples.

### Worked example

**Before you try it:** Know whether you need a reusable output or recovery of all work.

Compare a saved task pack, a model snapshot and a full backup for the same project. The pack remembers a selection; the snapshot freezes model content; the backup preserves broader local work.

**Expected result:** You can explain which file or record meets the task before using it.

**Common mistake:** The five-MB backup limit does not imply every other upload or cloud payload has the same limit. Use the specific tool instructions.

## 27. Owner guide: accounts and activity

This section is for Studio administrators only. Account administration, invitations, activity reports and access changes are described in the separate operator guide supplied to administrators. Everyone else can skip it; nothing here changes how you build or use a model.

### Worked example

**Before you try it:** Check whether your Studio account has the **admin** role.

Administrators open the operator guide and follow its account steps. Everyone else continues with the quick start in the next section.

**Expected result:** Administrators know where account steps live; other readers lose nothing by skipping this section.

**Common mistake:** Access to the hosting dashboard does not grant Studio's **admin** role.

## 28. Follow the quick start

New projects open **Quick start**. Its six steps follow saved work: confirm purpose and scope, define at least three terms, add a connection, review all definitions and connections, record a current manual question assessment, and download or copy reviewed knowledge. You can work in any order. A template's terms and links can satisfy the structural steps while still being proposals.

Choose **Start** or **Inspect** beside a step to open its tool. For the assessment step, record the actual answer, reviewer and explicit Pass, Partial or Fail result. Recording a current assessment completes that activity even if it fails; read the result and fix missing evidence before relying on the model. Checklist completion does not certify correctness.

The export step completes only after copying or requesting a download of a nonempty reviewed knowledge selection, with draft inclusion off. AI instructions alone, an empty export, a failed clipboard operation or printing do not complete it. Imported private terms require deliberately including private knowledge after review. Meaning changes make the assessment and export steps need attention again. Independent project copies need their own export.

In **Scope**, the next-step card links to **View all steps**. Choose **Hide checklist** to collapse it, or **Show checklist** to restore it. Visibility does not change your model version.

### Worked example

**Before you try it:** Use a new Glossary project.

Inspect the six Quick start activities. Starter terms may satisfy structural steps while remaining proposed. After you record a Partial assessment, inspect the question result as well as the checklist.

**Expected result:** The checklist shows that an assessment activity occurred; the assessment itself still records Partial.

**Common mistake:** A completed checklist is not a statement that the model passed every test.

## 29. Apply bulk term changes

Open **Bulk edit** from the project navigation or **Define terms**.

1. Select individual terms, **Select all**, or **Clear selection**.
2. Enter a new group, choose a source, or choose a review action. Blank group and **Keep current** options leave that value alone.
3. To approve the selected terms, enter the reviewer and confirm that you reviewed every selected definition and its evidence. This applies only to definitions, not connections or separate organizational usage.
4. Choose **Preview bulk changes**. Read every Before/After group, source and review value and the count of affected connections.
5. A source change returns its affected connections to proposed. Definitions also return to proposed unless you explicitly approve the new evidence in this batch. Moving private definitions to a public source requires a separate sharing acknowledgement; approve only content you are authorized to reuse.
6. Choose **Apply reviewed bulk changes**. The whole set applies once or fails together. Use **Undo last change** to reverse it during the current session.

Changing form values invalidates the preview. Project changes also require a fresh preview. Bulk editing preserves term IDs, definitions, aliases and independent projects. Group-only edits preserve existing review decisions, but advance the model version and therefore require fresh assessments and exports.

### Worked example

**Before you try it:** Select active terms and inspect their individual source/meaning first.

Select Team and Process and change their group to “Operations”. Preview the two Before/After records, confirm the set and apply it. Use Undo immediately if the grouping was unintended.

**Expected result:** Only selected records receive the change. The model version advances and earlier assessment/export progress may need attention.

**Common mistake:** Bulk approval applies to selected definitions; it does not approve their relationships or separate usage.

## 30. Import and export a vocabulary

Open **Vocabulary tools** (shown with **Show advanced tools**). Choose **SKOS vocabulary · Turtle** or **Studio Knowledge JSON**, then select a file or paste content. Files support up to 1 MB; input supports up to 200,000 characters, 1,000 concepts, and 10,000 RDF statements or 5,000 JSON links. Parsing happens locally and never fetches vocabulary URLs.

Choose **Preview vocabulary**. Inspect the proposed terms, connections, errors and omitted statements. SKOS imports preferred and alternative labels, definitions, canonical absolute HTTP(S) IRIs, and broader/narrower/related links. Multilingual literals are retained. Expand **Inspect retained vocabulary languages** in the preview or term inspector/review dialog to read every language before approval. The visible label/definition uses English, then untagged text, then the first available language. Narrower links become the inverse broader link. Missing definitions and invalid labels or structures block import; correct the source text and preview again. Unsupported RDF statements require an explicit acknowledgement before being omitted. This is a vocabulary importer, not full RDF/OWL ingestion or reasoning.

For Knowledge JSON, choose the filtered **Knowledge JSON** file from Studio **Use & export**. It carries supported term and connection content; imported approvals, reviewer identities, original source records, preferences, history, organizational usage and raw documents are omitted. Use **Restore backup** for complete project recovery.

Name the new project, set its namespace, acknowledge reported omissions and choose **Create vocabulary project**. It opens as an independent project of private proposals. Accepted definitions have a new private import source; existing projects stay intact. Review definitions and relationships before reuse. Private imports stay excluded from default sharing and read-only links.

To export, open **Use & export → SKOS vocabulary**. Apply the same draft/private/term selection used by other formats. SKOS writes a concept scheme, labels, definitions and broader/related links using preserved canonical IRIs where available. Object, datatype and subclass connections are omitted and counted in the output comment. Choose **Knowledge JSON** or **RDF / Turtle** to retain those connection kinds. A SKOS broader term is a vocabulary relationship and does not assert OWL subclass membership. Editing the primary label/definition updates its retained language literal; other translations remain and should be reviewed for consistency.

For safe round trips, inspect omissions on every import and keep a full Studio backup alongside any filtered vocabulary export.

### Worked example

**Before you try it:** Use a small authorized supported vocabulary; keep a full backup for recovery.

Preview a SKOS file containing Team and its definition. Inspect its canonical IRI and any omissions, then import it as an independent private proposed model. Export SKOS after reviewing the desired selection.

**Expected result:** Supported labels, definitions and vocabulary links survive the reviewed workflow; omitted statements are visible.

**Common mistake:** A FIBO OWL file can contain unsupported axioms. A successful bounded vocabulary import does not establish complete OWL interoperability.

## 31. Continue your work across projects

With **Show advanced tools** on, the Studio opens **Continue your work** when you have projects; otherwise it opens My models. Its cards show active projects, last-opened time, scheduled review date, pending definition/connection reviews, source evidence gaps, questions needing assessment or retesting, and incomplete or stale mappings. Choose an action to open that project at the relevant tool. **Resume project** returns to its last recorded working page. Archived projects remain under **My projects → Show archive**.

Choose **Set review date** on a project's card to record the next date you want to inspect its knowledge. A reached date appears as a dashboard action. Clear the date to remove it. This does not certify the model, automatically approve anything, schedule email, or change the ontology version.

The backup action requests a full current-version download. The card records the request, not proof that the file reached a safe location; verify the saved file. A new model version or independent project copy needs its own backup request. Cloud accounts no longer expire automatically. This local dashboard does not produce the administrator account report or track other users; that report is separate on Accounts and activity.

Project visits, review dates and backup requests are workspace metadata, not meaning changes. For linked cloud projects, this metadata can be included in their private cloud saves. The dashboard does not upload unlinked guest projects.

### Worked example

**Before you try it:** Have two active learning projects and a full backup for each important version.

Set a review date on one project. Reopen Continue your work on or after that date and use its task to resume review. Archive the other project and inspect the active dashboard again.

**Expected result:** The review reminder appears for the dated active project; the archive preserves the other project outside the active list.

**Common mistake:** Review dates create visible reminders, not scheduled emails or automatic source refresh.

## 32. Merge, deprecate and restore terms

Open **Term lifecycles**. Choose an action, the term, an active replacement where needed, a reviewer and a reason; then choose **Preview lifecycle impact**. Read both definitions and sources, reference counts, review resets and resulting self-connections. Confirm the effect before choosing **Apply reviewed lifecycle change**.

- **Merge duplicate into another term:** keeps the chosen target's definition, kind, canonical IRI and evidence. The old label and aliases become aliases on the target. The old ID and its full original record remain marked merged, with a replacement ID. Current connections, evaluation-question term references, explicit task-pack selections and schema mappings are redirected. Resulting self-connections are removed from the current model and retained in lifecycle history. Changed definitions/connections return to proposed; mappings require review again. Existing retired replacement references are also redirected.
- **Deprecate a term:** retains its ID and definition as a retired record. Current references retain that ID and are flagged where they need repair. You may name a compatible active replacement. If other retired terms already point to this term, choose a replacement to preserve their redirects.
- **Restore a deprecated term:** returns the same ID to active proposed use, with affected connections requiring review. This does not automatically restore approval.

Merge/replacement targets must be different active terms of the same modeling kind. A merge can still be rejected if its resulting model would be invalid, for example a hierarchy cycle. An explicit extra acknowledgement is required before private labels become aliases of a public target. Separate organizational usage remains on its original retired record; it is not silently transferred.

Normal knowledge/context/RDF/SKOS exports and read-only snapshots exclude retired terms and incident links. Full backups and private cloud projects retain their records. Historical snapshots and assessment models are frozen and keep their original references. A historical snapshot can therefore include a term that was active at that time.

Use **Undo last change** during this session to reverse an action. Restoring a deprecated term is an explicit new change; splitting a merged term is not automated. Recover a prior merge from session Undo or an independent full-backup restore. Changing the project after preview makes a fresh preview necessary.

### Worked example

**Before you try it:** Back up first and compare the meanings of the two candidate terms.

For an invented duplicate DeliveryTeam with the same scope as Team, preview a merge into Team. Inspect transferred aliases and affected connections/questions/mappings before applying. Deprecate instead when the old meaning is simply out of current scope.

**Expected result:** The kept meaning remains inspectable; the retired ID and lifecycle history remain in full backups.

**Common mistake:** Do not merge two concepts merely because their labels resemble each other; the action can redirect many current references.

## 33. Map a schema and export a data dictionary

Open **Schema mapping**. Choose **CSV header row**, **JSON field example — values discarded**, or **JSON Schema — object properties**. Paste content or select a CSV/JSON file. Files support up to 1 MB and pasted input up to 200,000 characters. Extraction supports 500 fields, 12 nested levels and 200-character field names.

Choose **Extract fields & suggest matches**. CSV retains only the header; rows after it are discarded. A JSON field example retains exact field paths and observed types, never sample values. JSON Schema retains property paths, declared types and descriptions; constraints, defaults and example values are omitted. Arrays remain array fields. Referenced schemas are not fetched. These are metadata mappings, not validation of real records or executable queries.

1. Name the mapping and describe what one record or field set represents.
2. Inspect each assignment, definition, evidence and review status. Suggestions use matching term IDs, labels and aliases; ambiguous names stay unmapped. Choose the intended active term or leave the field unmapped.
3. Add mapping notes. Use **Next fields** and **Previous fields** for more than twelve fields; assignments and notes remain available across pages.
4. Enter the mapping reviewer and tick the review confirmation only after inspecting field assignments and assumptions. Unticked saves proposals. Mapping approval does not approve draft ontology terms.
5. Choose **Save mapping**. This stores field metadata and bindings, discards the source input and preserves the ontology version. Up to 30 mappings can be saved in each project; each edit advances that mapping's own revision.
6. Choose **Inspect / export** on a saved mapping. Default dictionaries include reviewed mappings and approved public terms. Include proposed mappings/draft terms or private definitions only deliberately. Unmapped and filtered fields are omitted; JSON reports their count.
7. Choose CSV or JSON, inspect the output, confirm you have permission to export its metadata and definitions, then choose **Download dictionary**. CSV neutralizes spreadsheet-formula prefixes. JSON includes exact path arrays, grain, mapping revision, model version and term/source IDs.

Changed mapped meaning, source references, review state, canonical IRI or retirement makes bindings stale and blocks export. Choose **Review / edit**, inspect the current definitions and save fresh review decisions. Changes to the model while an editor is open require re-extraction or reopening the saved mapping before saving.

Full backups and private cloud projects retain mappings. Normal ontology exports, context packs and read-only links do not automatically include schema metadata. A dictionary is a separate explicit export. Source sample records are never stored with it.

### Worked example

**Before you try it:** Use the learning model with reviewed Team, Process and Outcome meanings.

Select CSV header row and paste `team,process,outcome`. Extract fields, inspect suggested bindings, name it “Service specification”, describe the grain as one service specification, and save a reviewed mapping after inspection. Preview and download its dictionary.

**Expected result:** The dictionary explains eligible field-to-term assignments. No CSV record values are stored.

**Common mistake:** Reviewing the mapping does not approve a draft term. Stale bindings require a fresh review before export.

## 34. Learn from a worked example

Open **Examples**. It starts with the ten-minute 5G tutorial and example topics (5G network, Coffee brewing, Library catalog and Retail). Below them, four business demonstrations cover service delivery, consulting recommendations, policy intent and evidence, and data product accountability. Each card explains the task, expected result and walkthrough.

Choose **Open worked example** to create an independent project. It includes a scoped synthetic model, clearly labeled demonstration review records, two synthetic manual assessments, a three-field reviewed dictionary, a saved knowledge task pack and a frozen baseline snapshot. These illustrate recording a workflow; no real client, AI model or compliance result was tested. A persistent banner identifies the starting example.

Inspect **Scope**, **Define terms**, **Connect**, **Evaluation questions** and **Schema mapping**. Download readable domain evidence and the dictionary to see their intended downstream use. Change a definition and observe which reviews, assessments and mappings need attention before reuse.

Choose **Download example package** from the library for a fresh synthetic package. It contains a restorable full Studio backup plus readable evidence, instructions and CSV/JSON dictionary outputs. **Restore backup** can open its project independently. The library download always builds the catalog's synthetic example, not the currently edited project.

To adapt an example to real work, replace conventions and demonstration identities with your own authorized evidence and reviewers, then make fresh review and assessment decisions. The synthetic-origin banner remains visible so the original demonstration is not mistaken for external authority. Use normal full backups for your edited project.

### Worked example

**Before you try it:** Choose a synthetic example whose question matches what you want to learn.

Open Explain a service delivery model. Inspect its source conventions, synthetic assessment records, three-field dictionary and baseline. Revise one definition and observe the resulting retest/review work.

**Expected result:** You see a complete workflow and its change consequences without treating demonstration results as a real evaluation.

**Common mistake:** The library Download example package always produces the catalog example, not your edited project.

## 35. Build a local knowledge collection

Open a project and choose **Knowledge research**. Create a named collection for a methodology, practice glossary, engagement or domain. Collections are scoped to this project. The feature reads selected inputs; it does not connect to an internal repository or upload an entire vault.

1. Optionally enter a source owner and declared version/effective date.
2. Choose local TXT, Markdown, CSV, HTML, PDF or DOCX files, or select a document folder. Files support up to 5 MB; choose no more than forty at once. Browser folder support varies; selected files work as an alternative.
3. Alternatively, paste a named document and choose its format. For a public page, enter its HTTPS URL, confirm permission to retrieve/use it and choose **Fetch & inspect page**. Only that selected page is requested through the Studio service. Local collections are never sent with the URL request.
4. Inspect extraction status, warnings, passages and any Before/After text. PDF uses page locators; Markdown/text/DOCX use section or extracted-line locators. These are extracted-text positions; Word formatting and page numbers are not preserved.
5. Confirm local retention and choose **Store reviewed collection changes**. Until then, extraction is a session preview. Duplicate/unchanged files are skipped; failed rechecks preserve the prior usable copy.

Scanned PDFs need prior OCR and password-protected PDFs are unsupported. Script-only/login-protected websites, unsupported encodings and unavailable pages may fail; import an authorized saved HTML/text copy instead. No webpage scripts or document instructions are executed. Each document supports 200,000 extracted characters and 1,000 passages; the project supports ten collections and 1.2 million extracted characters. PDF extraction supports up to 100 pages.

Use **Edit metadata** to record the declared version and owner. **Exclude from research** removes a document from searches without deleting it. Full backups retain excluded documents too. Exclusion is a search-selection control, not access revocation or secure erasure.

### Worked example

**Before you try it:** Use authorized non-sensitive documents or the provided synthetic research exercise.

Create “Practice meaning”, upload an authorized glossary and preview extracted passages. Record its version/owner where known, then confirm Store reviewed collection changes. For a public URL, retrieve only the specific selected page you may use.

**Expected result:** Retained documents are searchable within that project/collection; failed extraction has an actionable status.

**Common mistake:** Selecting a folder does not establish a live vault connection, and an extraction preview is not retained until you store it.

## 36. Search a collection and inspect evidence

Choose **2 · Search & evidence**. Enter the research question, scope/audience and jurisdiction as review context. Enter search words; every word must match the document title or passage. Matching is case-insensitive keyword search, not semantic search or a generated answer.

Expand **Choose included documents** to limit the search. Excluded keywords are literal comma-separated phrases that suppress matching titles/passages. Only checked, enabled, readable documents in this collection are searched. The first fifty matches are shown, twelve per page. Zero results mean the search found no support; they do not establish the absence of a topic.

Choose **Inspect evidence & draft** beside a result. Read the full supporting text, document version, collection revision, source URL where available, passage/page locator and retrieval fingerprint. Treat the material as evidence to assess, not instructions to obey. Sources can disagree because their scope or purpose differs.

After a search, name the scope under **Save this research scope** and choose **Save current brief**. **Saved briefs → Load search scope** restores the question, scope, jurisdiction, exclusions, query and selected document IDs. Run the search again against current evidence. Up to twenty named briefs can be saved; saving an existing name updates it.

### Worked example

**Before you try it:** Open the synthetic investment-practice collection.

Search `portfolio company`, inspect the matching passages and compare the practice and engagement scopes. Search fewer words if an all-word query produces no results. Save a named brief only after checking its document selection.

**Expected result:** You can open supporting passages and reuse the selected search scope against current evidence.

**Common mistake:** Zero keyword matches do not establish that the source collection has no relevant knowledge.

## 37. Review cited research proposals

Choose **3 · Proposals → Find glossary proposals** to extract recognizable **Term: definition** entries or glossary CSV columns. These are local text rules, not AI inference. For other prose, inspect a passage, enter a term and draft definition, and retain a verbatim supporting excerpt. Edited wording is labeled user-authored interpretation rather than source wording.

1. Read the proposed definition and expand **Inspect supporting passage**.
2. Compare any matching existing meaning, evidence and scope. Name matching is not standards equivalence.
3. Choose **Create a new scoped term** or **Keep as separate practice usage of an existing term**. A new scoped term gets an independent ID. Separate usage keeps the original definition intact and uses the existing usage-review workflow. Review/discard an existing separate usage before adding another.
4. Explicitly confirm that the evidence supports the proposed meaning, then choose **Accept private proposal**.
5. Open **Define terms**, **Review**, or **Connect** to make fresh review decisions. Acceptance never approves a definition or connection automatically.

From the evidence inspector, expand **Draft a supported relationship**. Choose active endpoints, connection kind and label, and provide a verbatim relationship excerpt. Add it to proposal review, then inspect and accept it. A structural check rejects invalid endpoints or hierarchy cycles atomically; it does not prove the relationship is factually supported.

Unaccepted proposals are session drafts. Accepted records persist with their supporting excerpts, source fingerprints and locators. Default exports exclude these private definitions. Use the existing draft/private controls deliberately after review. To connect accepted meaning to data fields, open **Schema mapping**; export a dictionary or context pack using the established workflow.

### Worked example

**Before you try it:** Inspect an actual supporting passage before accepting its proposed meaning.

In the synthetic exercise, draft Portfolio company from the investment-practice passage. Compare the engagement convention separately and keep it as practice usage if appropriate. Inspect the citation before Accept private proposal, then review the new model record.

**Expected result:** Canonical/local meaning is preserved and the new accepted record is still private and proposed.

**Common mistake:** Finding an exact quoted passage verifies its origin, not whether your interpretation or proposed relationship is correct.

## 38. Check coverage and recheck changed evidence

Open **4 · Coverage & checks** to inspect unreadable documents, missing declared versions/owners, missing source locators, short definitions, stale accepted evidence and questions with no assessment. Choose which metadata is required and a minimum definition length under **Your metadata checks**. These checks describe recorded evidence and work; they are not a completeness or compliance certificate.

Reimport a local file with the same path/name, or choose **Recheck page** for a saved public URL. Inspect Before/After text and the affected evidence count. Applying a changed document keeps definitions intact and resets affected term/usage/connection reviews. Historical snapshots and assessments remain frozen. A failed recheck keeps the previous usable copy.

When an accepted record needs recheck, choose **Review supporting evidence** in Coverage. Select a current supporting passage, read it, adjust its verbatim excerpt if needed and explicitly confirm it still supports the retained meaning. Choose **Rebind current evidence**. This updates the accepted source/excerpt, retains up to five previous excerpt records and requires review again. If the meaning no longer fits, edit/deprecate the term deliberately instead of claiming support. Recheck mapped dictionaries and evaluation questions after meaning/evidence changes.

The return dashboard links to unreadable or stale research evidence. Rechecking is on demand; this release schedules no web or repository monitoring.

### Worked example

**Before you try it:** Keep a baseline/full backup before applying a source change.

Reimport an exercise document with a revised definition and inspect Before/After. Apply it only after review. Open Coverage and rebind an accepted excerpt if the current passage still supports the retained meaning.

**Expected result:** The retained definition is not silently rewritten, and affected review/evaluation work needs attention.

**Common mistake:** Do not rebind an unrelated passage merely to clear a stale marker; revise or retire unsupported meaning deliberately.

## 39. Protect a practice collection and try the research exercise

All collection documents are private, retained in this browser and included in full project backups. They are excluded from cloud saves, normal context/ontology/dictionary exports and hosted snapshots. Cloud-only recovery cannot restore a local collection; keep full local backups.

Accepted excerpts become private project evidence under the existing source rules. Chosen linked cloud projects can save those accepted business-meaning excerpts and model definitions under the Studio cloud terms. Entire original documents are not uploaded. This release supplies no multi-user vault permission system or enterprise document repository. Keep content within the permitted business-meaning scope; do not use it for customer records, credentials or regulated personal data.

Choose **Open synthetic exercise** to add two clearly labeled invented investment-practice documents. Search for **portfolio company**, compare the investment definition with the engagement convention, accept one as a term and the other as separate practice usage. Save the research brief, inspect the pending reviews, map a field to the term and download a dictionary after review. The exercise supplies no real financial advice, measured AI result or authoritative standards alignment.

Reference links to FIBO, gist, OMG and IRO help you choose sources. Selected page importing is not full OWL ingestion; use **Vocabulary tools** for supported SKOS/Knowledge JSON files. SharePoint/OneDrive and Google Drive connections, live web search providers, owner-funded AI, OCR, authenticated collaboration and formal reasoning are outside this release.

### Worked example

**Before you try it:** Use the built-in invented practice documents for this exercise.

Open synthetic exercise, compare the two portfolio-company usages and accept only the meaning you intend to review. Download a full backup before moving to another device, then inspect which raw collection data is absent from a normal export.

**Expected result:** The full backup contains the local collection; a chosen filtered output contains only eligible accepted meaning.

**Common mistake:** Calling material “private” does not make the Studio an enterprise permission-managed repository.

## 40. Draft an ontology with OpenAI, Claude or a web account

1. Open **Knowledge research → LLM drafting**. Choose readable documents from your collection and enter a question, scope, jurisdiction and exclusions.
2. Choose **Prepare evidence package**. Expand **Complete drafting prompt and private evidence** and inspect what you intend to supply. Packages include only the selected documents, with evidence IDs, versions and locators; the limit is 60,000 evidence characters and 100 passages. Create a focused collection of authorized excerpts for a larger corpus.
3. For a web account, confirm the export and choose **Download ChatGPT / Claude package**. Supply that Markdown package to your chosen assistant after reviewing its data settings. Ask for the complete specified JSON response, then paste it into **Returned ontology JSON**, name it and choose **Inspect & save returned draft**. A ChatGPT or Claude web subscription can support this manual workflow; Studio does not log into your account or use its password.
4. For integrated generation, choose OpenAI or Claude. Under **Connection for this request**, choose a request-only key or your saved account connection if one is available. Request-only keys go directly in the password field. Choose **List models using this connection**, then select a text model supporting structured JSON outputs. Model discovery clears a request-only key, which you re-enter for generation. A saved connection stays on the server and is not returned to the browser. API access and billing are separate from ordinary web subscriptions; the $20 Claude Pro plan does not include Console API usage. This release uses API keys rather than subscription sign-in. Tip: let your password manager remember the key field rather than pasting it each time.
5. Name the draft, choose the maximum output tokens, acknowledge the selected evidence destination and API usage charge, and choose **Generate cited draft with BYOK**. Requests pass through the Studio service to the selected provider; request-only keys are never saved automatically, and saved account connections are used only when selected. Neither kind belongs in projects, browser storage, exports or application logs. Each generation requires fresh confirmation. Choose the package and provider before pasting a key, because redrawing the form clears it.
6. Inspect each returned proposal, its source passage and any reported gaps. For integrated API generation, the model chooses a supplied evidence ID and Studio attaches that ID's complete, unchanged passage. It does not ask the model to copy quotations or silently repair them. The saved inbox identifies this citation method. Inspect the passage for the claimed definition and relationship; the passage being authentic does not prove an inference. Keep conflicting definitions in separate scoped terms. Accept terms before their generated relationships so endpoints can resolve. Acceptance creates private, unapproved meaning. Review meanings in **Define terms / Connect / Review** before reuse.

**Citation corrections:** manual imports still require exact source quotes. If validation fails, the citation panel identifies affected proposals and source IDs. Expand an issue to compare the returned quote with the original passage and locator. The rejected JSON and import fields remain available in this tab; copy them before reloading or changing projects. Correct them deliberately and inspect again. The Studio does not save the invalid draft, alter the source wording, accept meaning automatically or make a paid retry. An unsupported relationship must be removed or reported as a gap even if its quote matches.

The package form reflects the selected saved question and scope. Editing these fields does not modify that saved package until you choose **Prepare evidence package** again. Inspect the selected package title and complete prompt before generation.

Set provider account spending limits before testing. Output-token limits bound size, not dollar cost; the provider may charge a started request even when you cancel or it times out. Studio makes no automatic retry. A failed, truncated, unsupported-model or mismatched-citation response is not applied. Reduce the selected evidence or output size and retry deliberately, or use the manual package. Generation has a 45-second service timeout; the browser timeout is 50 seconds for request-only calls and 60 seconds for saved connections. The revised source-selection flow passed a live Claude synthetic smoke test: four separate scoped term proposals and one supported relationship were saved privately, with original passages preserved and no items accepted automatically. This does not guarantee general semantic correctness. Live OpenAI acceptance is separate and remains pending. Each provider needs its own credentials, billing/model access and successful draft acceptance.

### Optional saved AI connections

Open **Cloud account → AI connections**. The vault is optional and available to invited signed-in users only when secure production encryption has been configured. A disabled notice means it is unavailable in that environment; it is deliberately disabled in Deploy Previews. You can continue with request-only keys. Signing in or entering a request-only key does not save it.

To save a connection, expand **Save OpenAI connection** or **Save Claude / Anthropic connection**. Enter your provider API key, confirm your Studio password, read the linked Saved AI Connections policy and tick its separate saving consent. Choose **Save encrypted connection**. This does not run a generation. The server stores encrypted credentials separately from project data and can decrypt them to carry out your requests; this is not a vault that only you can decrypt.

Choose **Test connection** to check authentication through model listing. It sends no corpus or generation prompt. It does not prove that all models are available or the account has funds. Return to **Knowledge research → LLM drafting**, select the provider and **Use my saved connection**, and confirm each generation's evidence destination and charge. Six starts per minute and fifty per hour are technical safeguards, not dollar caps. You still manage provider funding, alerts, limits and permitted use.

Use **Replace connection** with a new key, fresh password and saving consent to rotate it in Studio. Use **Remove connection**, confirm your password and tick the removal acknowledgment to remove it from Studio. A busy connection must finish or its reservation expire before replacement/removal. Revoking the key at the provider is a separate action and is the prompt response to suspected exposure. A started provider request may still complete or be billed.

Signing out retains your saved connections for later sign-in. Deleting all cloud data deletes saved connections too; restored account access does not recover them. Administrators see provider/status/date/outcome metadata and last reported token counts; they cannot reveal or use your key through the administration page. Privileged infrastructure operators may technically control decryption. Never include a key in feedback, a project, an assistant prompt or a support message. Contact RJL without the key if you suspect a security problem.

**Saved-connection example:** With a dedicated authorized Claude API key, save the connection and test model listing. Select it for a synthetic practice evidence package, confirm the provider charge, and generate a draft. After review, remove the saved connection. **Expected result:** No key is present in the project, its backup or the admin report; no future Studio request can use the removed connection. **Common mistake:** Removing it from Studio does not revoke the key with Claude.

### Worked example

**Before you try it:** Start with a focused collection and an authorized destination; no real key is needed for the manual exercise.

Prepare a package for “Define portfolio company within this practice”. Inspect its evidence IDs, locators and instructions. Download it for a permitted assistant, then return only its required JSON using the actual package runId and exact supporting quotes. Inspect and save the returned draft.

**Expected result:** Validated proposals and reported gaps appear for human review. Nothing is accepted or approved by generation alone.

**Common mistake:** A web-account password or subscription is not a BYOK API key. Never paste a key into the glossary or assistant prompt; provider requests still require consent.

## 41. Recover and compare generated drafts

**Saved draft inbox** retains up to ten drafts and ten evidence packages in the current project. Full backups include them; cloud saves and shared links exclude them. Download a full backup before changing browser, clearing site data or moving between preview and production origins.

Choose **Review saved draft** to recheck current evidence and recover its remaining proposals. Accepted items are tracked so they are not silently accepted again. If a supporting document, version, title or locator changed, prepare a fresh package; the saved historical draft remains available in your backup but cannot be reused against changed evidence.

To compare assistants or prompt attempts, generate or import two drafts using the **same saved evidence package**. Choose the first and second drafts under **Compare drafts from the same evidence**, then choose **Compare saved drafts**. Inspect added, missing, identical and differing terms/relationships and the reported gaps. Comparison does not score correctness, combine definitions or approve a model. Manual-import provider/model labels are user-entered; API labels and token counts come from the response.

Remove finished drafts deliberately after backup. An evidence package with saved drafts cannot be removed until those drafts are removed. Existing session undo can recover a removal during the session.

### Worked example

**Before you try it:** Keep two saved responses tied to the same unchanged evidence package.

Compare one draft that uses the investment meaning with another that scopes it more narrowly. Inspect changed terms, relationships and gaps, then choose which proposals to review rather than averaging their definitions.

**Expected result:** Differences remain visible and source checks still apply; comparison does not select a winner automatically.

**Common mistake:** Two drafts from different evidence packages are not comparable through this same-evidence workflow.

## 42. Upload documents and check release readiness

**Knowledge research → Collection → Upload documents** opens your normal browser file picker. **Choose folder** selects a local folder in supporting browsers. You can also drag files onto the drop area. Ordinary users do not need to change Chrome settings, install an extension or grant the site access to the whole computer. Only selected files are read; preview extracted text before retaining it. Extraction of local files runs in the browser. Supplying a package to an LLM is a separate explicit choice.

Supported files are TXT, Markdown, CSV, saved HTML, PDF and DOCX, up to five MB each. Scanned PDFs need OCR first; password-protected PDFs, XLSX and old DOC files are unsupported. Use an authorized text export instead. If a corporate device policy blocks file selection, your administrator must allow it; the application cannot override that policy. Folder selection may be unavailable in a browser, in which case use **Upload documents**. The optional ChatGPT browser automation extension has a separate file-access setting for automated testing; ordinary site users do not need it.

Open **Coverage & checks → Download readiness report** to save private project metadata: pending term/relationship review, practice usage, current assessments, questions needing retest, stale evidence, unreadable documents, schema mappings and health findings. The report contains counts and record IDs rather than document text or definitions. Use the linked review/evaluation screens to address findings. This checklist supports a release decision; it is not factual certification, regulatory compliance or automatic publication approval.

### Worked example

**Before you try it:** Use a small selectable local document or synthetic file.

Choose Upload documents, select the one file and inspect extraction. Retain it deliberately, then download the readiness report from Coverage & checks and inspect pending/stale counts.

**Expected result:** Ordinary upload works through the normal picker without browser-setting changes; the readiness file contains metadata rather than raw source text.

**Common mistake:** A scanned image-only PDF needs OCR before import. Repeatedly uploading it does not add the missing text layer.

## 43. Discuss a review and record its decision

Open **Practice workbench → Review decisions**. Practice work is saved in this browser and full backups. Cloud-only recovery, ordinary ontology exports and hosted snapshots do not contain discussions, blueprints or reference alignments. Keep a full backup before moving devices or clearing browser data. These are local review records with user-entered names, not authenticated team approvals.

1. Choose Term, Relationship, Source reference or Local source passage. Enter a target search and choose **Find targets**; up to 100 matching targets appear.
2. Select the target and expand **Inspect current target content**. This shows its current meaning, metadata or passage in your local workspace.
3. Enter the review question, objection or note and your name, then choose **Open discussion**.
4. Choose **Comment / record decision**. Enter a rationale and choose Comment, Request clarification, Accept discussion decision, Reject discussion decision or Reopen for review.
5. Save the entry. Earlier entries remain in **Complete decision history**. Accepting a discussion records its resolution; approve the actual definition/relationship separately in its editor.

Changed meaning, source metadata, relationships or passage revisions make the decision **Needs recheck**. A missing/retired target preserves its history and becomes **Missing target**. Record a fresh decision after inspecting the new target. A comment alone does not make a stale decision current. The return dashboard and readiness report include unresolved practice work.

The initial limit is 100 discussions and 50 entries per discussion. Private note bodies and reviewer names enter a client report only after explicit private/discussion inclusion and full report inspection.

### Worked example

**Before you try it:** Have an active term and a question about its scope.

Attach a discussion to Team: “Does this include outsourced delivery groups?” Record a clarification and the rationale for accepting or rejecting that scoped interpretation. Then edit the definition and inspect Needs recheck.

**Expected result:** The discussion history survives while the changed target requires a fresh decision; the term has its own approval state.

**Common mistake:** Accept discussion decision resolves that discussion, not the term editor approval.

## 44. Save and reuse a practice blueprint

A blueprint extends the starter templates with your selected definitions, connections, scope, linked acceptance questions and modeling-check preferences. It excludes original documents, history, personas, discussions, API keys and recorded assessment answers. Its content starts as proposals without carried reviewer identities; source attribution and private source kinds remain intact.

1. Under **Use & export**, choose the terms to reuse, or leave all eligible terms selected.
2. Open **Practice workbench → Practice blueprints** and name the blueprint. Reviewed, non-private source meaning is the default. Deliberately include labeled proposals or private meaning only when appropriate.
3. Choose **Preview blueprint** and inspect **Complete blueprint content**, including scope, examples, notes, source summaries and acceptance criteria. Free text may contain confidential information even when private imported definitions are excluded.
4. Confirm the selected content and choose **Save blueprint**. It is saved with this project's local practice work.
5. Under **Your reusable blueprints**, choose **Preview / use blueprint**. Blueprints from other active projects in this browser are also available. Inspect the content, enter a new name and namespace, and confirm reuse.
6. Choose **Create independent project**. It opens in Quick start. All definitions and relationships need fresh review, and no previous assessment passes carry forward. Review retained external canonical IRIs before publishing under a new namespace.

**Inspect / download** produces a portable blueprint JSON after confirmation. **Import a Studio blueprint (.json)** previews a downloaded blueprint before saving it. A blueprint is a reusable starting point, not a full project backup. Selected questions are included only when they have declared terms and every supporting term is in the blueprint; inspect omissions in the preview.

The limit is 20 blueprints per project, 500 terms and 1,000 relationships per blueprint. Projects with practice work must remain within the five-MB full-backup limit. Removing a saved blueprint leaves independent projects intact; Session Undo or a full backup can recover it. Later blueprint changes do not update projects already created from it.

### Worked example

**Before you try it:** Choose reusable business meaning, not client-specific working history.

Save a blueprint of Team, Process and Outcome with a linked acceptance question and chosen modeling checks. Inspect all source/scope notes, then create “Service ownership — second exercise” from it.

**Expected result:** A new independent project opens with proposals, its own question IDs and no inherited assessment passes or reviewers.

**Common mistake:** Later changes to a saved blueprint do not update projects already created from it.

## 45. Prepare a client-ready knowledge report

Open **Practice workbench → Client report**. The report is a readable delivery artifact containing selected definitions, connections, evidence references and optionally private review history, linked acceptance questions, current reviewed reference mappings and milestone changes.

1. Set the term selection in **Use & export**. The report uses those terms and their eligible connections; approved meaning from non-private sources is the default.
2. Choose whether to include labeled proposals or private business meaning. Review notes, reviewer names and linked acceptance questions additionally require **Include private review notes...** and private inclusion.
3. Optionally choose a saved milestone for a comparison. Both versions use the same draft/private/term filters. The report lists added, removed and changed records; it does not expose old private definitions merely because a public current version is selected.
4. Choose **Prepare report preview**. Read the complete embedded report and **Inspect complete report data**, including purpose, scope, examples and source notes.
5. Confirm the intended recipients and choose HTML or Markdown, then **Download reviewed report**. A changed project requires a fresh preview before downloading.
6. Open the self-contained HTML file in your browser and use its normal Print / Save as PDF command. The Markdown file can be edited in a text editor. The report's logo, layout and styles require no remote font or image download.

Original document text, API keys, personas and assessment answers are excluded. Selected accepted business-meaning excerpts can appear in private definitions/source summaries; inspect all output. The report does not prove correctness, regulatory compliance or an enterprise security implementation. It creates a file, not a hosted share link or an automatic publication.

### Worked example

**Before you try it:** Know the recipient and choose eligible terms in Use & export.

Prepare a client report of the three learning terms, leave private/discussion inclusion off and inspect every page of the embedded preview. Compare with a saved baseline if useful, then confirm and download HTML or Markdown.

**Expected result:** The chosen report contains readable meaning and references; HTML can be printed through the browser.

**Common mistake:** A private-excluded report can still contain sensitive free-text scope or source notes. Inspect actual content, not just its selection label.

## 46. Refine a model around a business question

Add a question and expected answer under **Evaluation questions**, then open **Practice workbench → Question refinement**.

1. Select the question. Inspect declared supporting terms, their review state, connections among them, missing/retired references and the recorded assessment status.
2. Inspect matching labels that have not yet been declared. Select the ones that actually support the question, confirm them and choose **Add selected question links**. Label matches are suggestions, not evidence of an answer.
3. Review **Possible gaps to investigate**. These are significant words in the question without matching labels; they may be ordinary language rather than missing concepts. Edit the question or use them to frame a focused investigation.
4. Select a knowledge collection and edit the refinement focus and draft scope/criteria. Choose **Continue to selected-evidence drafting**.
5. In Knowledge research, select the documents, prepare and inspect the evidence package, then use the existing manual handoff or BYOK workflow. Nothing is sent to a provider by the question-refinement action itself.
6. Review cited proposals, then record a fresh assessment against the revised model/question. Changed supporting terms or criteria can invalidate earlier assessment passes.

This is a guided lexical and review workflow, not an OWL reasoner, automatic semantic completeness assessment or generated factual answer. The drafting scope supports 2,000 characters; the suggested criteria may be shortened, so inspect and edit them before generation. BYOK still needs your funded API key and per-request destination/charge confirmation.

### Worked example

**Before you try it:** Have an Evaluation question with explicit criteria.

For “Who owns a process?”, inspect declared terms and label matches. Add Team or Process as dependencies only if they support the question. Select a collection and stage a focused investigation through Continue to selected-evidence drafting.

**Expected result:** The question has deliberate supporting-term links, and the drafting form receives a scope to inspect before choosing/sending evidence.

**Common mistake:** Possible gaps are unmatched words, not automatically discovered missing ontology concepts or factual conclusions.

## 47. Configure additional modeling checks

Open **Practice workbench → Modeling checks**. Enable the checks relevant to your practice and choose **Save check preferences**.

- Alias names used across different modeling kinds.
- Connection labels used for different relationship kinds.
- Repeated connections, including symmetric related links.
- Identical definitions reused on different terms.
- Evaluation questions without declared supporting terms.

Choose **Inspect record** or **Inspect question** beside a finding, decide whether it is a real modeling issue, then edit the relevant record. The first 100 additional findings are shown; resolve them and check again. Existing **Knowledge health** checks still run. Broken references, incompatible connection kinds and hierarchy cycles remain blocked by the core model validator even if optional practice checks are disabled.

Warnings do not establish factual contradiction or noncompliance. Check preferences are included in blueprints and full backups. Formal SHACL validation and OWL reasoning are separate future capabilities.

### Worked example

**Before you try it:** Use a synthetic model where two differently scoped terms share a label/alias.

Enable Alias names used across different modeling kinds. Compare a class label with an identifier alias using the same word, inspect the warning and clarify the intended labels or scope.

**Expected result:** The finding helps you investigate ambiguity. Core invalid-structure checks remain enforced when optional warnings are disabled.

**Common mistake:** A warning can identify a legitimate distinction; it is not proof that a definition is false.

## 48. Compare and align a reference vocabulary

Open **Practice workbench → Reference alignment**. This keeps external/reference definitions separate from local practice meaning. Imported files are user-supplied; metadata is not independently verified and does not grant reuse rights or publisher endorsement.

1. Paste or choose a supported SKOS Turtle / Studio Knowledge JSON file and choose **Preview reference vocabulary**. Inspect errors, unsupported statements, canonical IRIs and retained definitions. This is not arbitrary OWL ingestion.
2. Select a bounded subset, name it and record publisher/steward, version, URL and reuse/attribution metadata. If terms are unknown, say so. Acknowledge omissions and confirm permission to retain the selected definitions as private work.
3. Choose a local active term, the reference subset and a reference concept. Read both definitions side by side.
4. Choose Related, Reference is broader than local, Reference is narrower than local, or Exact meaning in the declared scope. Record a scope/rationale and the evidence locator or sections compared.
5. To mark a mapping reviewed, name the reviewer and explicitly confirm both meanings and evidence. **Preview alignment**, inspect the decision and confirm saving. Exact meaning requires its own confirmation; identical labels are insufficient.
6. Changed local meaning or reference metadata marks the mapping **Needs recheck**. Use **Inspect / recheck**, examine the current definitions and save a fresh decision. The existing local definition is never automatically replaced.
7. Explicitly include private mappings, choose **Preview mapping export**, inspect complete eligible output and confirm its destination. Download JSON for definitions/rationale/attribution, or SKOS Turtle for reviewed mapping assertions. Empty, stale, proposed or unapproved-local mappings are excluded; the current term selection from Use & export also applies.

Broader/narrower mapping directions are from the local concept toward the reference. Exports use SKOS relatedMatch, broadMatch, narrowMatch or exactMatch, not OWL equivalence. Mapping assertions remain separately exported and do not enter ordinary ontology exports or hosted snapshots. Preserve the JSON decision/attribution alongside Turtle when recipients need the explanation.

The initial limits are ten reference subsets, 200 selected concepts per subset and 500 mappings per project. Up to 200 concepts appear in an import selection; provide a smaller subset if the needed concept is outside that selection. Practice references are local/full-backup data and have no live standards refresh, licensing verification or authenticated collaborative review.

### Worked example

**Before you try it:** Have a small supported reference vocabulary, reuse metadata and an active local term.

Import a bounded synthetic Team reference, read it beside your Team definition and choose Related meaning unless your scoped review supports another mapping. Record a rationale and locator, preview and confirm it. Export only current reviewed mappings for approved selected local terms.

**Expected result:** Local and reference definitions remain separate, with a scoped mapping and provenance. Exact meaning needs an additional explicit confirmation.

**Common mistake:** Identical labels do not establish exact meaning, OWL equivalence, publisher endorsement or permission to redistribute a standard.


## Learning center and guided practice

Open **Learning center** from workspace navigation (shown with **Show advanced tools**). Begin with a synthetic exercise, or create a project to follow **Build from documents**. This joins collection choice, extraction inspection, retained passages, acceptance, definition/relationship review, question assessment and output inspection. Step links use the existing tools. No step automatically calls an LLM or grants approval.

Choose **Client report**, **AI context** or **Schema dictionary** to see eligible output under the same selection as Use & export. A dictionary also needs saved mappings that pass current binding checks. Counts are actual eligible content; they do not prove factual correctness or completed assessment. Private proposals can remain excluded even after approval. Review the recipient and selection rather than turning on private inclusion automatically.

**Reading mode:** Beginner opens optional walkthroughs. Reference folds them for quick lookup. Field help stays visible in both modes. The user guide uses the same choice to fold worked examples without removing task links. Guide links from editors open separately and keep your unsaved inputs.

**Exercise packs:** download the starter pack, inspect/edit its JSON and choose Preview pack. Review prerequisites and expected artifacts, then Retain reviewed exercise pack. Owner packs are saved in this browser and exported separately from project backups. Open an exercise to create an independent proposed project; no approvals or assessment passes are inherited. Author only synthetic learning material. Existing IDs cannot be overwritten through import.

**Clips:** captioned synthetic walkthroughs and annotated screenshots explain starting an exercise and inspecting an output/backup. Pause or read the transcript at your pace. Check the labels against the current UI.

### Worked example

**Before you try it:** choose the VC investment-practice exercise with no real deal or client records.

1. Start the independent exercise. Explain why Fund, Manager and Portfolio Company have different definitions.
2. Inspect synthetic convention evidence and record separate term and connection reviews.
3. Record your answer to the distinction question manually.
4. Choose AI context in Learning center. Inspect eligible counts and the same term/private/draft selection in Use & export.
5. Request the context download and a full project backup; verify both files.

**Expected result:** bounded practice meaning with a recorded assessment and inspected output. The downloaded exercise instructions are a separate learning artifact from the project recovery file.

**Common mistake:** treating a checked progress condition, accepted proposal or requested download as a verified result. Inspect the underlying meaning, recorded assessment and saved file.

## Give Studio feedback

Choose **Give feedback** in the website bar, or **Give Studio feedback** in the footer. The website form opens separately so your Studio workspace stays available. It works for guests and invited users.

1. Choose the feedback type: a blocker, feature suggestion, documentation/learning question, something that worked well or other feedback.
2. Describe the task and what happened or would help. For a problem, use synthetic steps, the expected result and the actual result.
3. Review your text. Do not include private project content, client information, personal data about other people, keys or regulated data. Nothing from your project, account or documents is attached automatically.
4. Optionally provide your email for a reply, then choose **Send Studio feedback**. The confirmation page acknowledges receipt; it does not promise a feature or date. This is not a subscription or an access request.

**Worked example:** choose Feature suggestion, enter “Review a synthetic service glossary” as the task and describe the missing guidance using invented terms. Leave email blank if you do not need a reply.

**Owner review:** open the website's Netlify Forms dashboard and choose **studio-feedback**. Submissions are separate from Studio access requests (`working-session`) and whitepaper subscriptions (`newsletter`). A successful synthetic form submission and owner receipt still need live acceptance after the website release. Email notifications for this new form may be configured in Netlify if wanted; feedback is available in Forms without adding an email delivery service.