Work on copies first
Start with a sample project or a duplicate of a few scenes. The evaluator writes output back into Markdown frontmatter, so test the write path before touching a working draft.
Privacy and safety
Use local tools deliberately, and protect the draft first.
ObservaStory is designed for local, writer-owned story evaluation, but privacy depends on the way you install the tools, make backup copies, and decide what can leave your computer.
Use at your own risk
Free, experimental software is not a privacy guarantee.
ObservaStory Workbench is provided as an experimental learning project. It does not guarantee privacy, security, correctness, data recovery, uptime, compatibility, or fitness for professional use. You are responsible for your manuscript files, backups, automatic copy settings, plugin choices, local model configuration, and anything you choose to share.
Safest starting path
Begin with a copy, offline tools, and no automatic publishing.
The lowest-risk first test is boring on purpose: use a disposable sample folder, keep network-dependent services out of the loop, confirm every file change, and only then move toward a real manuscript.
Keep AI local
Use a local model runner such as Ollama for offline evaluation. Do not switch to hosted AI APIs if your goal is to keep manuscript text off third-party servers.
Pick one file home
Keep the test project in one ordinary folder you can find. Do not scatter copies across several apps before you understand what each one is doing.
Review before sharing
Check current files, generated notes, screenshots, logs, and online folders before sending anything to another person or service.
Backup and version choices
Choose one file-safety plan before using a real manuscript.
Think of an Obsidian project as a folder full of text files. A backup is an extra copy. Sync means a tool automatically copies changes to another device or service. Version history means you can go back to older saved states. Publishing means other people may be able to see the files.
New-user recommendation: start with one local folder plus dated manual copies. Add automatic sync or advanced version history only after you know how to restore yesterday's work.
Choice
Plain meaning
Good for
Watch out for
Dated manual copies
You copy the project folder yourself and name the copy with the date.
Beginners, first tests, and peace of mind.
You must remember to make copies, and copies can take space.
Computer or drive backup
Your operating system or backup drive saves extra copies for you.
Recovering from a broken computer or accidental deletion.
Make sure you know how to restore one folder, not just the whole machine.
Automatic cloud copy
A service copies changes between devices or into an online account.
Working on more than one device.
Mistakes can sync quickly, and private files may be stored by a third party.
Private version history
A tool keeps a record of file changes so advanced users can go backward. Examples: Git/GitHub/GitLab, Apple Time Machine, Dropbox version history, or Obsidian's own version history.
People who already use tools that track file changes over time.
Private must really mean private, and old versions may still contain deleted text.
Public sharing
Files are placed somewhere other people can see or download them.
Finished samples, documentation, or material you truly intend to publish.
Do not use this for unpublished manuscripts or private story notes.
Do not do these
Common ways a private story can accidentally become public.
Most leaks are not dramatic hacks. They are usually an automatic copy setting, a public folder, a browser extension, or a plugin doing more than the writer realized.
- Do not put a manuscript in a public online folder, website, or code repository unless you intend to publish it.
- Do not paste unpublished scenes into web chatbots, hosted editors, browser extensions, public issues, or support forums.
- Do not expose the Ollama API or any local scheduler endpoint to the public internet.
- Do not install random Obsidian community plugins into a manuscript folder just to experiment.
- Do not rely on automatic copying as your only backup, especially while scripts are editing frontmatter.
- Do not share screenshots, support logs, terminal output, or bug reports without checking for private story text, file paths, repo names, and email addresses.
Known risk areas
What each piece of the toolchain can affect.
ObservaStory is a local workflow made from several moving parts. Each one has a different risk profile, so the safest setup is the one you can explain in plain language.
Area
Primary risk
Safer habit
Ollama and local models
A local model runner can still be misconfigured, logged, exposed on a network, or confused with a hosted AI service.
Keep it local, avoid public network binding, download models before going offline, and verify which endpoint the config uses.
Obsidian plugins
Community plugins run inside the writing environment and may read, write, sync, display, or transform files.
Install only the plugins you need, read plugin documentation, and test on a sample folder first.
Templater and JavaScript
Scripts can modify files quickly and may make network calls if written or configured to do so.
Run one scene first, inspect changed files, keep scripts from untrusted sources out of the manuscript folder.
Online file history
Tools such as GitHub can reveal current files, older versions, generated metadata, and private folder names if visibility is wrong.
Treat this as an advanced option. Keep manuscripts private and understand old-version history before publishing.
Automatic copy tools
Cloud folders and backup tools can copy sensitive files, create conflicts, or preserve unwanted versions.
Choose one backup strategy deliberately, keep restorable snapshots, and pause sync while testing batch edits if needed.
Generated analysis
Scores, rationales, Truth Ledger claims, and frontmatter can reveal spoilers, character details, and plot structure.
Treat generated metadata as manuscript material, not harmless diagnostics.
Sharing for help
Screenshots, logs, copied errors, and support requests can expose private paths, repo names, generated metadata, and story text.
Use a sample project when asking for help, and review anything copied from your screen or terminal before posting.
Offline use - for the ultra-paranoid about privacy
Offline work requires preparation before you disconnect.
ObservaStory can be used without an active internet connection when the needed tools, plugins, scripts, and model files are already installed. Test that path on a sample project before relying on it for a real manuscript.
Prepare while online
Install Obsidian, Node.js, Ollama, plugins, templates, scripts, and model files before disconnecting.
Disconnect deliberately
Turn off Wi-Fi or unplug networking, then run one disposable scene and confirm the output is written locally.
Reconnect thoughtfully
After offline work, review generated files before allowing automatic copy tools or cloud backups to copy changes elsewhere.
Vocabulary bridge
When the documentation says "vault," think "project folder."
Obsidian's help pages use the word vault for the folder where your notes live. ObservaStory uses that same folder-based approach: your scenes are ordinary Markdown files on your computer. The privacy question is not the word "vault." The privacy question is which tools are allowed to copy, change, remember, or publish that folder.
Copy
A backup copy gives you somewhere to return if something goes wrong.
Remember
Version history keeps older states. That can save you, but it can also preserve text you thought was deleted.
Publish
Publishing or public sharing is different from backup. Only do it for files you truly want others to see.