TwinEthosRequest access

Control

No human review/data-correction path after adverse ADMT decision

After an adverse ADMT-influenced consequential decision, the consumer must be able to request data access/correction and meaningful human review + reconsideration.

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Family: AI decisions lack effective human review, override, or contest · control id cond.no-human-review-or-data-correction-on-adverse-admt

Reach

2items this one guard addresses
0jurisdictions where binding law on it is in force
1more where it is enacted, not yet applying
1standards and frameworks on the same control

enacted, not yet applying in Colorado (US-CO); next date 2027-01-01.

The guard to add

Give people who receive an adverse AI-influenced decision a way to see and correct the data used and to request human review that can change the outcome.

Built into the adverse-outcome path: when a decision is adverse, the system saves the personal-data inputs the model used with the decision, and the letter or screen that communicates it links to two routes. A data access and correction route (GET/PATCH /me/data, correct_input_data) shows those inputs and accepts corrections of inaccurate data, which send the decision back for re-run or review; a reconsideration route (POST /decisions/{id}/reconsideration, request_human_review) places the case in a review queue where a reviewer with authority to change the outcome records reviewer_id and override_reason.

Where it goes: 1 application source code, 9 AI output handling, 15 agent action surface, 2 data models.

What reviewers look for: for each adverse outcome that is saved and communicated, the inputs used stored with the decision, a person-facing route to view and correct them, and a reconsideration request that lands with a human reviewer who can change the outcome (reviewer_id, override_reason recorded); links to both routes in the adverse-outcome message.

Example (FastAPI), before:

if result['decision'] == 'denied':
    applications.save(app_id, status='denied')
    send_email(applicant.email, render('denial.txt', applicant=applicant))

After:

if result['decision'] == 'denied':
    applications.save(app_id, status='denied', inputs_used=features, model_version=MODEL_VERSION)
    send_email(applicant.email, render('denial.txt', applicant=applicant,
               data_url=f'{BASE}/me/data', review_url=f'{BASE}/decisions/{app_id}/reconsideration'))

@app.patch('/me/data')
def correct_input_data(fix: DataCorrection, user=Depends(current_user)):
    corrections.create(user_id=user.id, field=fix.field, value=fix.value)
    review_queue.enqueue(user.latest_decision_id, reason='data_corrected')

@app.post('/decisions/{decision_id}/reconsideration')
def request_human_review(decision_id: str, user=Depends(current_user)):
    review_queue.enqueue(decision_id, reason='consumer_request')   # reviewer can change the outcome

Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.

Upcoming dates

Every rule this guard addresses

Binding law — not yet in force or stayed (1)

Standard / soft law (1)

Related incidents

No guardrail sits on this exact control; these incidents are cited by guardrails on related controls.