Using Counterpedia with agents and software
What this chapter does
An agent can help you search and summarize, but its answer is much more useful when it keeps the specific records, sources and versions behind what it says. This chapter shows the full read-and-follow task without treating a software response as a new verdict.
Reader outcome
Configure a documented client, read an identified record, follow a source reference through another permitted read, and compare what the agent receives with the human view of the same object and edition.
Before you begin
Choose Counterpedia’s maintained API, SDK or MCP documentation for a supported read operation, and use an authorized client where access requires one. Start from a Boeing 737 MAX record only if the chosen collection actually returns it; otherwise use another real identified record. Follow the interface’s documented identifiers and response format rather than guessing an endpoint or tool name.
1. Choose an interface and read its contract
Select the interface appropriate to your client: direct HTTP API, an SDK that uses the same documented operations, or an MCP tool for an agent. Read its discovery resources, schemas, supported version and access rules.
Do not infer feature parity from a shared brand. An MCP read tool need not be a write API, and no documented read grants authority to execute Check or publish new material.
2. Configure a client with the right identity
Use the provider’s maintained connection or authentication instructions. Confirm which account or principal the request represents and whether it is limited to public records. Keep secret values out of example outputs and screenshots.
Expected result: an authorized client ready to make one explicit read. If authentication fails, resolve it as an access problem rather than fabricating a successful response.
3. Read a Boeing object
Submit the exact identifier using the documented read operation. Inspect what was returned: object type, subject identity, release or edition, known provenance, cited source references and any explicit unavailable fields.
A readable paragraph is not enough to prove that the correct object was selected. For Boeing, distinguish a subject overview from a specific investigation record or document.
4. Follow a source reference
Choose one returned source reference and follow it using an operation that explicitly accepts its identity. Compare the document’s publisher, title, version, custody state and permitted destination with the original record. A reference is not a guarantee that Counterpedia retained a copy, and an agent must not construct a plausible-looking URL in place of a returned link.
If the second read is unavailable or refused, keep the reference and state the boundary.
5. Compare human and agent views
Open the same record and edition in the human interface. Check that both representations carry the same identifying context, relevant source distinctions and unresolved matters. Formatting can differ; claims about scope or support must not expand between clients.
For example, an engineering investigation’s cited causal findings cannot automatically become a claim about the knowledge or culpability of every individual involved.
6. Inspect an existing receipt without rerunning Check
Where the documented interface permits reading a receipt, identify its issuing operation, object reference and recorded questions. Distinguish receipt lookup from the separate verification procedure and from initiating a new Check. A transport wrapper, result envelope and canonical receipt content can be different byte sequences. Use the verifier’s specified representation, not whichever JSON happened to be easiest to copy.
7. Navigate limits and diagnose failures
A bounded result may offer pagination or a cursor. Continue only as the documented interface permits, carrying the release and selected scope forward. A schema error means the request did not match the contract; a not-found or permission result means the requested read did not return that material. Never fill missing data with guessed fields.
8. Carry the work to another client
Use the returned identities and public or permitted inspection destinations in a second application or agent. The new client should be able to identify the same record and source edition without inheriting access to the first user’s private results. Follow licence and attribution requirements for reused material.
9. Finish with a reusable citation
A successful example consists of the named object, its version, at least one attributable source reference, the authorized read operation, and a second-client explanation that leaves uncertainty intact. It does not require running Check.
For related tasks, see Saving and exporting and Understanding evidence and uncertainty. Use the maintained client instructions for installation and connection; a different interface may require different operations or permissions.
Optional tutorials
The main procedure does not require these exercises. Choose a tutorial for a field-level comparison, or skip to the closing explanation below.
| Tutorial | Output |
|---|---|
| Verify a receipt with its documented verifier | Verifier report, covered-field modification, and verification-input references |
| Distinguish a subject from documents about it | Two-object identity comparison and the connecting reference |
Skip the optional exercise and read the closing explanation.
Tutorial: Verify a receipt with its documented verifier
Use the Boeing SEC XBRL exercise to inspect a supplied receipt and verify its supported properties with the verifier documented for that release. Keep receipt verification, raw-file comparison, and assessment execution as separate operations.
Starting material
Use the exercise’s identified receipt, retained artifact, and verification instructions. The instructions must identify the receipt format, verifier version, supported profile or procedure, and any schema, keyring, trust bundle, or companion artifacts required by that verification path. Retain the source of each trust input separately from the material being checked.
This exercise starts with an identified artifact and receipt. It does not repeat source discovery, acquisition, or admission. The Boeing SEC XBRL filing and Boeing aviation-safety records are different source sets. A shared company name is not a verification binding between them.
1. Identify the receipt and verification procedure
Record the receipt identity, its declared format or profile, the associated artifact reference, and the properties the selected verification procedure checks. Use the release’s documented verifier instructions for that procedure. Do not select a profile merely because its name looks plausible.
For material covered by the selected procedure, the supported properties are independently verifiable with the documented verifier. That description does not turn every Counterpedia result or raw file into a signed receipt.
2. Verify using the required inputs
Run the versioned verifier command supplied with the exercise. A documented command may have this form:
VERIFIER_COMMAND PATH_TO_RECEIPT --trust-inputs PATH_TO_TRUST_INPUTS --profile PROFILE_ID --json
Replace the arguments with the exercise’s recorded inputs. This is an interface template, not a bound Boeing command. Other supported receipt or artifact-chain formats use their documented procedures and companion inputs. Do not force one format through another profile.
Retain the complete report and exit status. Read each finding by its name and declared scope. An unreadable input or an unsupported profile must be corrected before interpreting the result as a verification finding.
Expected result: a report for the specified receipt and verification inputs, with the properties evaluated, their outcomes, and any separately reported chain result. Compare it with the exercise’s recorded expected findings rather than assuming a successful outcome.
3. Test a controlled modification on a copy
Keep the original receipt, retained source, and trust inputs unchanged. Make a disposable exercise copy and change one field that the selected verification procedure covers. Rerun the same procedure using that copy and the original verification inputs.
Record the changed field and the new findings. For a signature-verification exercise, use a covered field value, not JSON formatting: a verifier may authenticate canonical content rather than raw file layout. The verification procedure determines which changes it detects.
Expected result: the relevant finding changes for the altered input, or the report identifies why the comparison was not evaluated. If an exercise expected failure but the result is unchanged, inspect the procedure’s coverage; do not relabel an unchanged result as a detected modification.
4. Separate receipt verification from byte comparison
The companion worksheet contains compare_bytes.py for comparing a raw file with an expected SHA-256. Use it only when that expected digest describes the exact raw-file representation. Keep the expected value’s source with the comparison.
The worksheet is a byte-comparison exercise, not the documented verifier. It performs no signature check, profile verification, assessment rerun, or independently witnessed time check. Comparing bytes with a digest from the same untrusted download establishes self-consistency, not an independently trusted origin.
Output and completion check
Keep the receipt and artifact identities, verifier version, selected procedure, required trust-input references, original report, modified-copy report, and modification description. Recheck the original after the exercise. Explain which properties each report evaluates and which remain outside its scope. Do not extend these findings to accounting truth, proposition support, or proof that the underlying event occurred.
Apply the procedure elsewhere
Repeat on an authorized receipt or exported artifact from a different example. Select its own documented verification procedure and trust inputs; do not reuse the Boeing profile, digest, or keyring without an explicit applicable binding. For a raw-file-only export, use the separate worksheet and report only the byte comparison.
Return to Agents and software, or compare the distinction with assessment scope.
Corresponding overview
Work with Counterpedia programmatically