> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fidel80.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Documentation Maintenance

> How Fidel80 developer documentation is updated, reviewed, and kept in sync with the platform.

The Fidel80 developer documentation should be treated as version-controlled product documentation.

## Source of truth

The Fidel80 application and backend codebase remain the source of truth for supported developer behavior.

Documentation should only describe functionality that has been implemented and validated.

## When documentation must be updated

Update the developer documentation when a product or API change affects:

* API authentication,
* GraphQL queries or mutations,
* request inputs or responses,
* workflow behavior,
* Smart Capture links,
* webhook events or payloads,
* security behavior,
* error handling,
* environment or deployment guidance,
* supported integration methods.

## Documentation standards

Each page should:

* use clear, consistent Fidel80 terminology,
* describe only verified functionality,
* use copy-paste-ready code examples where useful,
* avoid exposing real credentials, tokens, or personal data,
* use placeholders for environment-specific values,
* keep API paths, field names, and event names consistent with the codebase,
* explain prerequisites and expected outcomes,
* include troubleshooting for common failures.

## Change workflow

When a developer-facing change is implemented:

1. Complete the code change.
2. Run relevant automated and manual tests.
3. Confirm the final implemented behavior.
4. Update the corresponding Mintlify page.
5. Run `mint validate`.
6. Review the documentation in local preview.
7. Submit the documentation change through the team's version-control and review process.

## Validation before publishing

Before publishing a documentation change, confirm that:

* all navigation links work,
* code examples match the current API,
* no real API keys or secrets are present,
* no unimplemented features are described as available,
* `mint validate` passes.

## Review ownership

Developer-facing changes should include a documentation review as part of the definition of done.

The developer or team implementing the change should confirm whether the developer documentation must be updated before the change is considered complete.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.