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

# How to read the platform assessment

> The evidence behind documentation access, template operations and test environments, with clear limits on what each finding proves.

The [platform assessment](/platform-assessment) answers practical connection questions. It records what is known now and what the implementation team still needs to establish.

## Read the answer and its scope

| Answer | Meaning |
| - | - |
| Yes | Evidence supports the stated, scoped capability. It does not mean Triage has connected to the client's tenant. |
| No | Evidence explicitly excludes the stated capability. A failed search is never enough. |
| Conditional | A documented route needs a stated permission, subscription, configuration or vendor arrangement. |
| Unverified | The reviewed material does not settle the question. |
| Not applicable | The operation does not apply to this kind of platform or assessed object. |

Documentation existence, our ability to read it and permission to call the API are separate questions. A product page may describe integrations without publishing an endpoint reference. A retrieval failure may reflect JavaScript or tool access; it does not prove that the vendor keeps its documentation private.

## The questions we record

1. Does developer documentation exist, and can we read the relevant reference?
2. How does the platform accept data? How can it return data or events?
3. Can we open a specific existing template, create a record from it, create a template in the UI, or create a template through an API?
4. Is there a developer or test environment? Is it free, paid or provisioned through a client or partner?
5. Can the client grant Triage access to its test environment? What permissions and commercial entitlement need confirmation?
6. Has the proposed route actually been tested in that environment?

Each finding contains its answer, scope, source links, review date and evidence basis. A repository evidence review is labelled separately from a vendor page read in this pass. The current baseline includes a source-access observation for every execution destination; it is not an exhaustive search of every page in every vendor portal.

## Templates need four answers

**Open a template** means a supported link or action selects the agreed existing template for the requester. **Create from a template** means an API or supported workflow creates a new record using it. **Create a template in the UI** means a suitably authorised administrator can define the reusable form. **Create a template by API** means a documented machine operation can create that definition.

List, read, edit, copy and import operations do not automatically prove that a new definition can be created. Record the exact object and method. A Fieldglass Decision Form template, an SOW template and a job-posting template are different objects.

## Test environments need an owner

Record who provisions access: the developer programme, vendor, Triage, MSP or client. Record whether the environment is a reference mock, developer instance, staging/UAT tenant or production. A free test mode is not necessarily an isolated sandbox, and a vendor's public API explorer may use sample data only.

Client allocation stays conditional until the client confirms its environment, permitted integration use, administrator, credential scopes and test data. Keep credentials and client-specific grants outside this public register.

## Confirming receipt at L

Evidence should identify the destination tenant, native record ID, stored Intent ID and observation time. A successful file upload or accepted job is insufficient if it only queues work. Read the record back, or use an authenticated destination event that proves the same relationship. A native event without the reference may trigger a read; it is not itself proof that the ID is present.

Broader lifecycle synchronisation is a separate scope. The L promise is confirmation of the linked record, not a full bidirectional copy of the destination.

## Maintain a useful audit trail

The canonical findings live in `registry.json`. The platform table, detailed destination sections and CSV are generated from that source. Changes are reviewed through Git history, with the source, date and reason recorded in each assessment's review log. Do not overwrite an evidence date merely because a link still returns a page.

The carrier evidence ladder remains separate: cited, specification-checked, fake-tested, sandbox-tested and tenant-tested. A passing mock test never upgrades a platform to a live customer connection. [Carrier evidence](/concepts/carrier-evidence) explains that existing ladder.

When a client supplies access, record the test outcome and a sanitised evidence reference. Promote only the capability that was demonstrated. Keep sales discovery moving while unanswered questions remain visible.


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