GitHub Evidence for Agent Answers: Merged, Released, and Enabled
Use a three-state evidence ledger to distinguish merged code, released artifacts, and capabilities enabled for a specific audience.
An agent answering a product-availability question needs to distinguish code that was merged, a version that was released, and a capability enabled for the caller's environment. Build a change-evidence ledger around those three states before turning GitHub activity into a customer-facing answer. This guide defines that ledger rather than choosing a source connector or importer.
Key takeaways
Merged, released, and enabled are different evidence states
- Record the question's target: product edition, environment, audience, and requested date.
- Separate the three claims: merged code, released artifact, and enabled capability need their own evidence.
- Keep contradictory evidence visible: an announcement and a restricted rollout can both be current records.
- Answer at the demonstrated state: a merged pull request alone does not establish customer availability.
Define what available means for the question
In a hypothetical product, a pull request adds CSV export. The release notes later mention the change, but the rollout owner enables it only for a pilot workspace. The question "Can our production users export today?" concerns that workspace and date, not just the repository's latest code.
Write the target before collecting evidence: capability, product/version, environment, eligible audience, and effective time. If the question omits one of those details and it changes the answer, ask for it or state the scope supported by the available record.
The ledger is an authoring and review pattern. It is not a claim that AKB supplies feature-flag management, deployment detection, or automated entitlement decisions.
Keep one row for each evidence state
| State | Evidence to collect | Claim it supports | What still needs evidence |
|---|---|---|---|
| Merged | Pull request or commit and its repository reference | The change entered that code line | A shipped version and relevant deployment |
| Released | Approved release record linked to the actual artifact/build/version | The linked artifact/build/version contains the named capability | Availability in the caller's environment |
| Enabled | Deployment or rollout owner's approved state for the target audience and time | The capability is enabled within that stated scope | Other editions, environments, users, or dates |
Record an unknown state as unknown. Avoid completing the chain from a title that says "launch" or an agent's reading of a pull-request discussion. The owner may have deferred the release, narrowed the rollout, or withdrawn the capability after a later incident.
A release note can help locate a release, but it may omit or overstate a feature; verify that the actual artifact/build/version contains the capability. Even verified release evidence is insufficient to establish a particular customer's access. Keep those claims separate rather than discarding one source because another adds a condition.
Preserve the source and the approved interpretation
For each row, keep the capability ID, source locator, source version or immutable reference where available, captured time, effective time, covered environment, audience, decision owner, and review status. Keep captured and effective times separate: importing a note today does not make today's rollout state true.
Use two linked records when the raw source and the approved interpretation have different purposes. One identifies the PR, release note, or deployment evidence. The other states the reviewed availability claim and its scope. This lets a reviewer revise the interpretation while retaining the underlying evidence.
The AKB README lists GitHub PRs, releases, and commits as akb-wiki inputs. That input scope supports collecting evidence; it does not establish the deployment or rollout state of another product. Record missing operational evidence through an approved source and named owner.
Before answering present availability, re-check current deployment, rollback, feature-flag, and entitlement evidence for the relevant environment and audience. Treat missing evidence as unknown, and enforce current source and audience access on both the evidence retrieved and the answer provided. A previously merged commit may later be reverted, so historical merge evidence does not prove the current branch still contains the change.
Resolve a hypothetical evidence conflict
Assume the following records describe the CSV export example. The dates and IDs are illustrative, not observations about a real product.
| Record | Recorded state | Scope | Answer consequence |
|---|---|---|---|
| PR-EXAMPLE-41 | Change merged | Main development branch | Code implementation exists |
| RELEASE-EXAMPLE-8 | Change included in a release | Version 8 | A released artifact contains it |
| ROLLOUT-EXAMPLE-2 | Enabled for the pilot | Pilot workspace only | Production-wide availability remains unproved |
| DECISION-EXAMPLE-3 | Production rollout pending review | Production audience | Hold the production-availability claim |
The reviewed answer should distinguish the released capability from the pending production rollout. It can cite the relevant records and identify the missing approval. It should not infer that every user has access because two earlier rows are complete.
When the rollout record changes, update the reviewed claim and its effective time. A request about an earlier date may still require the earlier approved state; label that historical question explicitly and apply the reader's current permission boundary.
Challenge the ledger with different questions
Test the same evidence against "Was the change merged?", "Which release includes it?", "Is it enabled for this workspace?", and "What was available on the specified date?" The answers should refer to different rows when the question requires them.
Add a withdrawn rollout, a feature enabled only in one edition, and a release note that conflicts with a later approved operational record if those cases exist in the workflow. Ask the business owner to resolve the conflict policy before scoring the answer. A later timestamp alone is not a universal authority rule.
Record incorrect availability claims separately from missing evidence. The first calls for correcting interpretation or retrieval. The second calls for obtaining the missing owner-approved state. Neither is solved by automatically adding more repository material.
FAQ
Does a merged pull request prove a feature is available?
No. It is evidence that the change was merged at that point in the code line, but it may later be reverted. Verify the current branch, linked release artifact, and the target environment's approved enablement state separately.
Which timestamp should the ledger use?
Keep capture time and effective time separately. Answer historical or current questions using the approved state for the requested scope and time.
Can AKB ingestion determine rollout entitlement?
No. The documented GitHub inputs provide source material, not automated rollout or entitlement decisions. Re-check current deployment, rollback, feature-flag, and entitlement records for the requested audience; treat gaps as unknown and enforce access controls on both retrieved evidence and the answer.
What if release notes and a rollout decision disagree?
Retain both sources, identify the specific claims and scopes, and ask the designated owner to approve the interpretation before making an availability claim.
Read the AKB documentation
Review the documented inputs and knowledge interface for your evidence-ledger workflow.
