T9CloudAdapter.GetExplanation through the dedicated synthetic AWS t9 endpoint, signed as t9 with normal IAM credentials and the configured report region. Decode the AWS JSON response first: its body field is a string containing the rendered report. Application service responses carry the native result and report receipt. Reports expire 24 hours from creation by default, and reading does not extend the deadline. See Diagnostic Response Headers for authentication, revisions, retention and acknowledgment.
The three tabs show one illustrative report from the same renderer fixture, not a production measurement. They carry the same report ID, revision, five event IDs and six fact IDs. Human and Agent text match that fixture; JSON preserves its complete public schema-2 document, with whitespace reflowed for readability. Source codes inside the report are identifiers, including ec2.local-projection.
To save a JSON report, use signed SDK retrieval with fmt: "Json". Decode the outer AWS JSON response, then parse its body string as the report JSON. Use the original owner’s IAM credentials and the dedicated t9 endpoint.
Read the report envelope first
Before interpreting an event, record:- Illustrative Human report
- Illustrative Agent report
- Illustrative JSON report
Follow events to evidence
Events are occurrences captured inside a named scope. Facts are assertions whose provenance describes how the adapter knows them. They serve different purposes. In the fixture:event-decisionsays the admission decision selectedreject.- Its
evidencefield points tofact-constraint. fact-constraintis Derived and points tofact-instanceas support.fact-instanceis Observed viaec2.local-projection, with row versionrow-v9and an observation time. The public report omits the private log-position snapshot;privacy.value-unavailablerecords that loss.- The bounded conclusion is that this evaluation recorded an instance dependency and selected rejection. It does not establish complete capture of everything the adapter could know.
Explain mode, and the report does not establish later state.
Distinguish evidence bases
An effective-configuration fact can show which mode, backend, tuning choice or revision was selected. A compatibility-difference fact can describe a known semantic difference. Neither becomes an observed provider effect unless the report names that observation.
PostgreSQL query-plan evidence
The planned PostgreSQL plan integration adds apostgres-explain fact containing full native JSON for an instrumented statement. Its committed-state-observation context is an estimate from a separate database observation, not the original transaction snapshot or proof that the statement executed. Full plans can contain application literals and are restricted to the exact report owner. Preserve those distinctions when reading estimated rows, costs and predicates; ordinary Explain support does not establish SQL-plan coverage in your installed release.
Planned, attempted and observed effects
Use these words precisely:- Planned: the adapter selected an operation, mapping or target field.
- Attempted: an execution path sent or began target work.
- Observed: the adapter received or read a named result.
Explain mode is not a deletion attempt.
For asynchronous operations, inspect the latest revision and the operation-specific status observation. A provider-assigned ID may be unavailable in an early revision, so later events should continue with the exact identity once known rather than guessing from a reused name.
Treat sequence as scoped capture order
The Human fixture explicitly says its timeline is “in capture order (not a cross-service clock).” A report sequence is useful for stable rendering and local reasoning. It does not prove global wall-clock order between independent producers. Use stronger causal evidence when available:causedByrelationships;- parent and child spans;
- intent and operation references;
- producer-local sequence values;
- facts that explicitly name their supporting facts or events.
Read partial and incomplete reports
A report can be readable before it is sealed. Record the revision and lifecycle on every read. A later revision may add target observations, retries, child work or limitations. When a report is partial:- do not acknowledge it as though it were final;
- poll the same report ID rather than replaying the origin operation;
- retain the native result separately;
- compare revisions monotonically and ignore an older snapshot that arrives after a newer one;
- treat missing facts as unknown, not negative evidence.
CompleteForInstrumentedScope describes capture within instrumented scope, not universal knowledge. This example instead has Unknown assurance because information was withheld by the public renderer; its limitations explain why. A sealed report is final, but sealing does not upgrade its assurance. An unavailable payload remains unavailable even when other facts are usable.
Authorization denial does not have one universal shape
Report availability depends on the service path:
The illustrative fixture contains an authorization fact with outcome
Allow. The request is rejected by the dependency constraint. Do not use it as an authorization-denial example.
Choose the next action from evidence
For this fixture, the next safe action is to inspect the named instance dependency and its current relationship to the VPC. It is not to issue the deletion again. If the observation is stale or unavailable, gather a current non-mutating observation first. For another report:- Identify the decision or failed step.
- Follow its evidence IDs.
- Check every fact’s basis, source, version and limitations.
- State what the evidence establishes and what remains unknown.
- Choose the smallest test that resolves one unknown without replaying an ambiguous mutation.