The Requester Said No Auto Approve. The Run's Own Cleanup Code Approved Anyway.
GitHub issue 5 against a2a-settlement/settlebridge-ai, filed 7 September 2026 and open at this record's own verification, reports that the marketplace's training-run completion routine marked a run's top ranked submission approved before any branch of its own code tested the AI reviewer's recommendation, and with no read of the parent bounty's own auto_approve setting at all, while the platform's ordinary submission path, on the identical affected revision, gated that same decision behind exactly that flag. This record independently confirmed the mechanism by reading the affected source directly, and confirms current main already carries a merged fix distinguishing hard, machine checkable compliance from a model's own quality judgment.
Event analysed: . This analysis was published on 8 September 2026.
None, on the affected revision this record independently confirmed. GitHub issue 5, filed against a2a-settlement/settlebridge-ai on 7 September 2026 and open at this record's own verification, states that training_service.complete_run marks a training run's highest scoring pending submission approved and its claim accepted, sealing the parent bounty completed, without ever reading the parent bounty's own auto_approve field and without ever branching on the AI reviewer's own recommendation before that approval. This record read the affected revision, 2ad5948d5d3c620f0a7d6991dbb0dc720421de80, directly. The approving branch is unconditional on the loop's own rank test, `if i == 0:`, and a local variable named `rec`, the submission's own AI reviewer recommendation, is computed on every iteration but referenced only inside the branches that handle submissions other than the winner; the branch that performs the actual approval never inspects it. Nothing in that function reads the parent bounty's own auto_approve column at any point. This record separately read the platform's ordinary, non training submission path, backend/app/routes/submissions.py, at the identical affected revision: it gates every AI driven approve, reject or partial-approve decision behind `if bounty.auto_approve and is_compliant_for_approval(compliance):`. The requester's own approval policy existed, in code, and was enforced exactly there. A second, alternate lifecycle path to the same effect, reached whenever a training run finished rather than whenever an ordinary submission was reviewed, simply did not consult it. The issue reports two production bounties settled through the unconditional path: 0da7254b-ca2a-4142-b560-fc7c114eb77e, whose stored deliverable the issue states was missing the required generated_by key and every required p50 forecast band value, scored 92 out of 100 by the AI reviewer with recommendation approve and issues: [], and b2b60c92-ae0b-4fba-af03-00a3a6a9f085, whose every training iteration scored 15 out of 100 with recommendation reject, one of whose two tied submissions the affected tie-break's own submitted_at DESC ordering still selected and marked approved. Both bounties are reported with auto_approve set to false, the requester's own explicit request for a human decision. This record could not independently re-fetch either bounty from SettleBridge's own production host, market.settlebridge.ai, which returned a blocked response to every attempt from this session's own network egress policy; the two bounty facts above are carried as the issue's own first party account, corroborated by this record's own direct reading of the affected and current source rather than by a fresh production read. Current main, commit d1bbf4ac10d6438ffc31b3440d6e6b26104109fe, which this record independently confirmed to be the repository's own current tip, rewrites the completion routine to load the parent bounty before any resolution, derive auto_approve from it, and run the settlement loop only when that flag is true, routing every resolution through a new module, training_gates.py, whose winner_may_auto_approve additionally requires the reviewer's own recommendation not to be reject, the numeric score to clear the run's own score_threshold, and, when a compliance object states it was checked, that the compliance object also states the deliverable passed.
Read the affected function directly and the defect is not that SettleBridge lacked an approval policy. It had one, and enforced it, one path over.
What the issue and the affected source together establish
GitHub issue 5, filed against a2a-settlement/settlebridge-ai on 7 September 2026 by a repository collaborator and open at this record's own verification, states its own defect precisely: a training run's own completion routine, training_service.complete_run, approved a top ranked submission before any branch of its own code tested the AI reviewer's recommendation, and never read the parent bounty's own auto_approve setting at all. This record independently read the affected revision the issue names, 2ad5948d5d3c620f0a7d6991dbb0dc720421de80, directly rather than relying on the issue's own excerpt.
rec = (sub.ai_review or {}).get("recommendation", "reject") on every iteration, then if i == 0: sub.status = SubmissionStatus.APPROVED, unconditional on rec, unconditional on any read of the parent bounty at all. rec is dereferenced only inside the elif and else branches that run for submissions other than the top ranked one. The parent bounty is loaded further down the same function, after every submission has already been resolved, solely to seal its own status to COMPLETED.The check existed. It was one path over.
This record separately read backend/app/routes/submissions.py at the identical affected revision, the platform's ordinary path for reviewing a single submission outside a training run. Its own AI driven decision block reads if bounty.auto_approve and is_compliant_for_approval(compliance): before any approve, reject or partial-approve branch runs. The requester's own auto_approve flag, set to false on both bounties the issue names, existed as a real, enforced gate on this path. Training run completion, a second lifecycle path reaching the identical effect, submission approval and bounty settlement, whenever a run finished rather than whenever a single submission was reviewed, carried no such gate at the affected revision. This record reads that as the mechanism's own defining shape: not an absent policy in the system generally, a policy that existed and worked on one path and was simply never consulted on a second path reaching the same consequence.
What the issue reports about two production bounties
The issue names two settled bounties this record could not independently re-fetch: SettleBridge's own production marketplace host, market.settlebridge.ai, returned a blocked response to every attempt this session made through its own network egress policy. What follows is carried at the issue's own first party evidence level, not as a fresh production read by this record.
Bounty 0da7254b-ca2a-4142-b560-fc7c114eb77e, titled NVDA 22-Day Ensemble Forecast, reportedly required six top level keys including generated_by and forecast band entries each containing a p50 value. The issue states the stored deliverable lacked generated_by, carrying generated_at and methodology instead, and that every forecast band entry carried mean rather than p50. The AI reviewer, per the issue, nonetheless asserted all required top level keys with correct data types and values, scored the submission 92 out of 100, recommended approve, and reported issues: []. The submission was approved and the bounty sealed completed. Bounty b2b60c92-ae0b-4fba-af03-00a3a6a9f085, titled AlphaSignal Ensemble: SPY 22-Day Forecast, reportedly carried two training iterations that each scored 15 out of 100 with recommendation reject. The affected tie-break orders pending submissions by score descending, then by submitted_at descending; on the tie, the later of the two iterations was selected and marked approved, reviewer notes reading Auto-resolved at run completion, highest scoring submission, while the earlier, identical scoring submission was marked rejected. Both bounties are reported with auto_approve set to false.
What current main already changes
This record independently confirmed, through a fresh shallow clone rather than the commit message alone, that a2a-settlement/settlebridge-ai's current main tip is commit d1bbf4ac10d6438ffc31b3440d6e6b26104109fe, titled fix(training): decide compliance in code and gate approvals on it, and that it explicitly names both production bounties above in its own description.
auto_approve = bool(parent_bounty.auto_approve) if parent_bounty is not None else False, and runs its own settlement loop only if auto_approve:. Each submission's resolution now routes through a new module, backend/app/services/training_gates.py, whose winner_may_auto_approve requires, in order, that auto_approve is true, that the reviewer's own recommendation is not reject, that the numeric score clears the run's own score_threshold, and, when a compliance object states it was checked, that the same object states the deliverable was compliant. Failing any of those conditions leaves the submission PENDING_REVIEW rather than approved, and the parent bounty is no longer sealed COMPLETED around a submission left pending this way.The same commit adds a second new module, backend/app/services/compliance.py, which this record also read directly. check_compliance validates a deliverable's own JSON content against criteria['custom_checks'] as JSON Schema draft 2020-12, through Python's jsonschema.Draft202012Validator, and never raises on a failing deliverable; the training harness must still be able to submit failing work and see its own gaps reported back. Absence of any authored custom_checks returns checked: false, compliant: false, a state is_compliant_for_approval treats as non blocking, since nothing was ever authored to check against, distinct by construction from a checked-and-failing result, which is treated as an authoritative block on approval regardless of what the AI reviewer's own score or recommendation says. The ordinary submission path, read again at d1bbf4ac, now shares the identical gate the completion path uses: if bounty.auto_approve and is_compliant_for_approval(compliance):. This record also confirmed the same commit changes the affected tie-break's own direction, from submitted_at descending to submitted_at ascending, stated in the commit's own message as matching the training harness client's own strict greater than comparison, so the server and the harness agree on which of two tied submissions is the kept one.
What this record does not establish
This record does not establish that commit d1bbf4ac is deployed to SettleBridge's own production marketplace host; nothing available to this session states or implies a deployment date distinct from the commit's own authorship date, and this record treats deployment status as unknown rather than inferring it from the commit existing on the repository's own default branch. This record does not establish that either bounty's own escrow tokens were actually transferred; the issue's own account states an economic impact in terms of settled bounty status, and this record preserves that distinction, submission and bounty status on one side, a confirmed token transfer on the other, rather than treating the first as proof of the second. This record does not establish that GitHub issue 5's reporter is a SettleBridge employee, contractor or otherwise privileged party; the issue is attributed to a repository collaborator and this record does not assume a relationship beyond what the issue itself states. This record does not claim the AI reviewer's own 92 out of 100 score reflects a specific, reproducible failure this session independently re-ran against a live reviewer; it treats the issue's own quoted reviewer output, and the specific missing keys the issue names, as the issue's own first party report, corroborated by this record's own reading of the current compliance module the fix adds specifically to stop delegating that exact class of claim to an ungated model judgment.
Terminal state is not authorization
A training run has to end somehow. Its own completion routine has to pick a winner, seal the parent bounty, and hand a transcript back to whoever is watching. None of that requires the routine to also decide that the winner is approved. Deciding a run is over and deciding a submission is authorized are two different facts, and this mechanism let the first one produce the second for free. The reviewer's own recommendation, reject, was computed and then set aside. The requester's own auto_approve setting, false, was never read at all. Relative rank, the highest score among the submissions a run happened to produce, stood in for both, because nothing on that one code path asked either question before writing APPROVED. That current main now asks both questions, on the same path the ordinary review already asked them on, is the fix; that a second path could reach the identical effect and simply not ask is the finding this record keeps.
Sources
This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.
Protocol evidence
This record does not assess these architectures. The connection runs through the Risk Registry requirement each one bears on, and these published authority architectures are what the evidence says about that requirement.
Protocol evidence related through AEW-001 Action without applicable policy
- Supports requirement
Agent Action Decision Protocol (AADP)
Shamik Saha, individual submission to the IETF
Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it
AADP's separation of a Policy Decision Point that must issue a permit before a Policy Enforcement Point performs an action is a direct response to actions that execute with no applicable policy at all. These failures support the need for that requirement. Claude Code's own current documentation, read directly, extends the same gap one lifecycle stage later than GitSpawn's own known example above: a plugin's bundled hooks fire as a host subprocess with no fresh model decision required, and a marketplace update is applied by version signal with no described mechanism to gate a change to that hooks.json specifically, the same absent decision point AADP's separation exists to supply. A preprint posted to arXiv on 3 September 2026, 2609.03884, states this exact class of update as its own subject; this record could verify only its title and author list, not its own specific claims. a2a-settlement/settlebridge-ai issue 5 extends the same requirement to an alternate lifecycle path rather than a later trust stage: a training run's own completion routine, training_service.complete_run, was itself an unmediated Policy Enforcement Point at the affected revision, performing the approving effect with no Policy Decision Point interposed at all, while the platform's ordinary submission path enforced exactly such a decision point on the identical class of approval. Current main's own remediation, read directly, gates that same completion path behind a new module, training_gates.py, read as response side evidence that the requirement now applies uniformly across both lifecycle paths.
This record is the cited evidence for this relationship.
- Supports requirement
Identity for AI, Agent IAM Core and Agent Gateway
Ping Identity
Requirement Ping's own Agent Gateway sits in front of MCP servers and applies McpValidationFilter, McpProtectionFilter and McpAuditFilter to validate protocol shape, enforce OAuth 2.0 resource server scope checks and audit each tool call before the backend is reached
Ping's own Agent Gateway sitting in front of MCP servers and running McpValidationFilter, McpProtectionFilter and McpAuditFilter before a backend request runs is a configured pre-resource enforcement point ensuring an applicable authorization decision exists for the MCP traffic it mediates, the corrective for an action that executes with no applicable policy at all.