Read the answer and its scope
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
- Does developer documentation exist, and can we read the relevant reference?
- How does the platform accept data? How can it return data or events?
- 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?
- Is there a developer or test environment? Is it free, paid or provisioned through a client or partner?
- Can the client grant Triage access to its test environment? What permissions and commercial entitlement need confirmation?
- Has the proposed route actually been tested in that environment?
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 inregistry.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 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.