Comparison

MarkBack is the text-first member of the annotation-tool family. It doesn't replace every alternative; it sits at a specific point in the design space — comments that live in files, in git, in your repo, with no server.

The table below names where MarkBack fits and where one of the alternatives is the better answer.

What	MarkBack	JSONL labels	Label Studio / doccano / Argilla	Markdown comments
Lives in your repo	✅	✅	❌ (server)	✅
Hand-writable in any text editor	✅	technically	❌ (UI-only)	✅
Lintable without a custom validator	✅	requires custom schema	n/a	❌
Pre-defined semantics for label + author + threading	✅	invent your own	✅	❌
Diffs cleanly in a pull request	✅	depends	❌	✅
Machine-extractable feedback	✅	✅	✅ (export)	requires convention
Annotates non-text files (images, PDFs, audio)	via sidecar	requires base64 or refs	built-in UI	❌
Multi-user collaboration UI	❌	❌	✅	❌
No server / no database	✅	✅	❌	✅
Cross-language tooling	Python + Node + browser + VS Code	language-agnostic file	server APIs (multi-language)	n/a

When MarkBack is the right answer

• You want to leave comments on files in a git repo and have them diff cleanly in pull requests.
• Your feedback workflow is asynchronous and text-first — prompt iteration, evaluator runs, code review of generated content, ad-hoc data labeling.
• You don't want to invent a custom JSON schema and a validator for it.
• You want the same format to work in Python, Node, the browser, and VS Code.

When something else is the right answer

• Label Studio / doccano / Argilla — your team is doing large- scale labeling and needs a hosted UI, role-based access, and a database backend. MarkBack is a file format, not a labeling team's workflow tool.
• Custom JSONL — you already have a strict schema and a pipeline that consumes it, and the schema is more elaborate than label + comment + attributes (e.g., bounding boxes, multi-class hierarchies). JSONL with your schema is a closer fit.
• GitHub PR review comments — you only need to comment on in-flight code review, not on long-lived annotations of data or prompts. PR comments are ephemeral; that's a feature for code review and a limitation for evaluation workflows.
• Markdown comments — your "annotation" is just a developer note that doesn't need to be machine-extractable. Use ordinary markdown.

Combining MarkBack with other tools

MarkBack files are ordinary text. They round-trip with anything that reads text. Common patterns:

• Export MarkBack → JSONL for ingestion into an existing eval pipeline:

  mb --list --json myfile.mb | jq '.records[]' > labels.jsonl

• Import from Label Studio by writing a one-off script that parses the LS export and produces MarkBack records via the Python or Node API.
• CI lint on every PR — add mb --lint ./**/*.mb to your CI pipeline. A pre-commit hook is on the roadmap.

The point of being a text format is that integration with anything else is "read the file and walk the records." Nothing custom is required on either side.