> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes.
> A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it.
> Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct.
> Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release.
# Quickstart
> Take one useful first action today, using only the parts of Nitsor that a visitor can actually reach.
Available now
Most quickstarts end with something running. This one cannot, because Nitsor is pre-release and there is no public sign-up, package, or sample workspace. What you can do in the next hour is decide whether the intended product fits a real decision your team already makes, and write down the evidence that would settle it.
## What you can reach today
* These documentation pages, plus a clean Markdown copy of each one at the same address with `.md` added.
* An `llms.txt` index, an `llms-full.txt` export, and four curated context bundles for AI tools.
* Documentation search.
* A [contact form](https://nitsor.com/contact) for product and design-partner questions.
Nothing here requires an account, and nothing here grants product access.
## Pick your first action
Find the row closest to your situation. Each row gives one page to read first and one action small enough to finish this week.
| If you… | Read this first | First action |
| -------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Annotate or review | [Annotate and review](/guides/annotate-and-review) | Bring one instruction, one representative task, and the current rule for returning or escalating work. |
| Run the program | [Release a dataset](/guides/dataset-release) | Map one release decision from source selection through approval and note the evidence you cannot reconstruct today. |
| Build integrations | [Plan an integration](/guides/plan-an-integration), then [Integrations](/reference/integrations) | Read the [public HTTP API](/reference/api) and [command-line interface](/reference/cli) contracts, then write the acceptance test a future package or service must pass. |
| Model data or contracts | [Data model and contracts](/reference/data-model) | Compare one of your own release records against the recorded contracts and mark what has no equivalent. |
| Make the adoption decision | [Product status](/product-status) | Define the smallest design-partner evaluation that could change your decision, separating conclusions that need a working product. |
| Read this programmatically | The `llms.txt` index, then the context bundles listed in [Integrations](/reference/integrations) | Load the smallest bundle that covers your question and cite the page source recorded inside it. |
Deployment and security requirements have their own evidence checklists in [Deployment and security](/reference/deployment-and-security) and [Self-host mechanics](/reference/self-host).
## If you get stuck
| Situation | What to do |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| You cannot tell whether a capability exists | Open [Product status](/product-status) and read the capability status matrix rather than the prose. |
| Search did not return the page you expected | Try a concrete noun from the [Glossary](/reference/glossary), or use the sidebar. |
| A documentation link is broken | Recover through the sidebar, record the page and the link, and do not substitute a private path. |
| The contact form rejects your message | Use the exact [contact form validation](/reference/integrations#contact-form-validation) constraints. |
| An agent answered without a source or changed a label | Treat the answer as unsupported and require the source URL and the quoted availability label. |
| You need legal, privacy, security, or compliance approval | Pause and involve the authorized owner; the public legal pages are drafts awaiting counsel review. |
## What to include in a useful question
* your role and intended outcome;
* the relevant workflow or decision;
* the page you already read;
* the availability or evidence point that remains unclear;
* the smallest piece of working evidence or test that would answer it.
The same limits apply here as in [Design-partner onboarding](/guides/design-partner-onboarding). Do not send credentials, patient or customer scan data, storage locations, or confidential material through a public contact form.
## Common mistakes and limits
* A contact message is not an authorization to access systems or data.
* A design-partner conversation is not a delivery commitment.
* A complete documentation path is not proof that the product path exists.
* Retrying does not turn an unavailable capability into an available one.
* A context bundle is not a substitute for reading the cited source when making a high-stakes decision.
## Next step
Read [Product status](/product-status), then record the exact evidence you would need before adopting the workflow you care about. If a focused design-partner evaluation is appropriate, continue to [Design-partner onboarding](/guides/design-partner-onboarding).
Outcome
Leave with one focused, truthful action and the evidence you still need to ask for.