[Use Case] Contextual trust under recursive human–agent escalation

Start with the short case · Read the complete dossier · Download the visual reading edition

For this package, this action and this moment: what can be relied on, what remains unresolved, and what must be reviewed before proceeding?

First publication edition, version 1.0; hypothetical and implementation-neutral. Submitted to FG-TIDA as an individual expert contribution; no acceptance, pilot execution or adoption is claimed. This summary follows the retained ten-section template and does not replace the dossier's requirements or evaluation designs.

Reading route: FG-TIDA fit · The situation · Requirements · Assessment · Duplication · Complete annex guide

FG-TIDA justification: This case contributes technical requirements (ToR 4.1), scoped trust metadata (4.4) and falsifiable assessment designs (4.5), addressing trust lifecycle and human oversight (4.3; Annex A.2.2/A.2.4). It tests the receiver's admission decision for a mixed human–agent specification-and-code package. Policy and authority remain external inputs, consistent with the scope exclusions in clause 2. This is a proposed mapping, not institutional acceptance. Official Terms of Reference.

Neighbors and separation, before the scenario:

Full source-specific boundaries are at the dossier's opening and Sections 4/7/H.9. The contribution proposes a testable composition question; it does not claim these groups lack the relevant concepts or cannot satisfy the case.

1. Identification

Title: Contextual trust under recursive human–agent escalation

Submitting organization: Individual expert contribution — Iván Abril Palma, The Integral Management Society / Tegrity.AI

Contact name: Iván Abril Palma
Contact email: ivan.abril@tegrity.ai

Sector:

• [x] Education
• [ ] Displaced persons / humanitarian
• [ ] Health
• [x] Financial services
• [x] Telecom
• [x] Media and publishing
• [x] Logistics
• [x] Energy
• [x] Critical infrastructure
• [ ] Smart home / IoT
• [x] Other: International IT pre-standardization and collaborative software engineering; downstream industrial variant in the dossier.

2. The situation

Plain language description: An international IT pre-standardization group develops specifications, code and tests for trust between humans and agents through GitHub. FG-TIDA can implement human escalation, but the human on that route can introduce an agent into the escalation pipeline; therefore, “human escalation” does not demonstrate that independent human judgment has occurred. The receiver must decide whether the resulting package has sufficient evidence for admission to a controlled testbed.

Narrative hook: Robots writing specifications for trust in robots.

Actor: Maintainer organization M; contributor organization S; requirement owner H1, contributor H2 and reviewer H3; drafting/coding agents A1/A2; review assistant A3 in the escalation extension; non-AI tooling T1; identity/authorization providers; evidence issuers; appraiser V; workflow W; auditor Q.

Action: Turn comments and sources into clauses, schemas, code, tests and a versioned executable package; review it and decide reversible testbed admission.

Decision required: May M rely on this exact package for this action, considering quality, required review, independence, authority, coverage, residual uncertainty and the time available for further evidence?

Problem encountered: Accounts, signatures and apparent agreement can conceal different production and review paths. An agent may draft a clause, implement it and generate tests from the same mistaken interpretation. A human-associated response may merely transmit another agent's recommendation. Later changes may invalidate prior review while familiar names and approvals remain visible. These are synthetic conditions, not allegations about actual contributors.

Current mitigation: Declarations, source citations, version-bound reviews, identity and delegation records, repository protections, build attestations, independent fixtures and workflow logs.

Residual gap: Whether these mechanisms, composed and correctly configured, preserve enough meaning and evidence for the receiver's specified decision. The case does not assume their inadequacy.

Working definition: Contextual reliance is the bounded decision to depend on a contribution or review for a specified task, artifact version, context, consequence and validity period, with evidence quality, coverage, independence and residual uncertainty stated. Actor type alone establishes neither superior quality nor adequate oversight.

Open the supporting routes: R0/R1/R2 evaluation · Measurement and escalation · Exact standards gaps

Concrete challenge: C0 requires missing mandatory approval evidence to remain NOT_ESTABLISHED. A controlled later change treats that absence as approval satisfied; candidate-derived tests may repeat the same error. Compare behavior against independently fixed C0 outcomes. An earlier approval for D2 does not silently cover D3. Testbed admission produces scoped observations, not a certificate that the trust framework is correct.

3. Actors and context

Taxonomy roles involved:

• [x] Principal
• [x] Relying party
• [x] Builder
• [x] Deployer / Owner
• [x] Agent instance
• [x] User
• [x] Infra provider
• [x] Attestor
• [x] Other: domain reviewer, evidence appraiser and auditor

Mandates in this case:

These are hypothetical policy relationships; actual jurisdictions and applicable legal regimes must be supplied by pilot owners.

Cross-border? [x] Yes — intended international collaboration; jurisdictions/hosting locations remain pilot inputs. [ ] No
Embodied? [ ] Yes [x] No — software/synthetic effects.
Agent action type: [x] Read-only [x] Consequential (reversible) [ ] Irreversible
Crosses organisational boundary? [x] Yes — M, S and evidence providers. [ ] No
Risk level: [ ] Low [x] Medium — stipulated bounded testbed [ ] High

Formal adoption, production deployment and binding external commitments are outside this decision.

4. Theme relevance

Related theme proposals: The opening and dossier Section 4 map the relevant proposals and Terms of Reference. Requirements are stated as case-derived functions, without prescribing a qualification approach. Dynamic Identity remains the base profile's primary theme; no theme reassignment is implied by this editorial summary.

Scope boundary: Policies and authority are external inputs. The case proposes technical evidence/appraisal requirements, not general AI governance, a new agentic protocol or national digital-ID content; these boundaries follow ToR clause 2. Submission placement should consider Continuous Trust and Attestation as primary for the evolved framing, without altering the frozen fixture.

5. Requirements

The following reproduces the 26 existing requirements from dossier Section 5. “Must” is a proposed case requirement, not an adopted standard.

The complete requirements and traceability remain in dossier Section 5 and its annexes. Its direct-reuse table links each condition to a concrete failure, existing HAP requirements and observable acceptance evidence. Scope/uncertainty, common dependencies, further-review capacity and targeted revalidation are already expressed in the case's own terms. Selected-extension conditions remain explicit; they do not silently change the base profile.

Reuse a native record or requirement directly when its meaning, subject, scope, evidence status and validity match. Do not require a renamed field or a new connector merely to pass. Any genuine semantic mismatch must be declared. All implementations face the same frozen expectations, including compliant positive controls and the possibility that existing mechanisms already suffice.

Function policy distinguishes personally required judgment, human authorization, assigned accountability and permitted automation. These conditions can coexist; independence and reviewability are additional qualifiers. A required human function is more precise than “100% human.”

6. Assessment criteria

Success criteria: Produce a version-bound, reconstructable decision with supported findings, unknowns and limits. Corrected compliant cases must advance. Always blocking, always trusting a human click or always returning unknown cannot pass.

Measurable metric: Unsupported positive review claims; erroneous acceptance and unnecessary holds; qualifier loss between adapters; material-change detection; requalification latency; reviewer effort. Compare human, agent and hybrid task outcomes under fixed rubrics without preselecting a winner. A calibrated probability of correctness cannot replace authority or mandatory review.

None of the 66 test designs in this use case (T01–T50, ES01–ES08 and MQ01–MQ08) has been executed as part of this publication. This statement concerns this case only and does not characterize execution status elsewhere in the wider reference corpus. Technical fixture IDs retain their existing suffixes for reproducibility; they are independent of publication version 1.0. Deterministic state checks and statistical performance evaluation are separate campaigns. Each assessment states what further evidence could help, who can obtain and assess it, and whether it can arrive before the intervention deadline. More observations within one branch do not close unobserved branches.

7. Duplication check

Existing standards or SDOs: C2PA/IPTC, W3C PROV/VC/disclosure work, IETF RATS/SCITT/OAuth, identity/observability ecosystems, NIST risk guidance and JCGM measurement guidance. Industry labeling examples include MIHR and Provenance Label. Exact versions, primary references and limits are in dossier H.9.

Overlap notes: Existing work already supports influence relationships, meta-provenance, assertion metadata, appraisal policies and uncertainty-aware decisions. The remaining question is whether the selected composition preserves and appraises review functions, dependencies, quality, coverage and contextual applicability sufficiently for this decision, including recursive human-to-agent delegation. No universal absence of a suitable profile is asserted.

Compare native controls, a strengthened composition and the proposed receiver profile under the same evidence/policy. If the existing composition suffices, report that result. Separate implementation, mapping and evidence gaps from a standards gap; failure in a selected implementation is not proof of a missing standard.

Selected primary references, with analysis in the dossier:

https://www.w3.org/TR/prov-dm/
https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html
https://datatracker.ietf.org/doc/html/rfc9334
https://airc.nist.gov/airmf-resources/playbook/measure/

8. Maturity

Pilot status: [x] Hypothetical [ ] Pilot in progress [ ] Deployed in production

Reference implementation: N/A for the combined profile. Pilot owners must validate process facts, evidence availability, policies and reversible boundaries; freeze selected extensions and independent expectations; then execute and compare implementations. No performance benefit is yet claimed.

9. IP and confidentiality

Confidentiality level: [x] Public — proposed synthetic contribution [ ] FG-internal only [ ] Redact before publication

IP notes: Public references and synthetic facts; no customer data or private transcript. Later code/data requires its own licensing and disclosure record. Attribution does not imply endorsement.

10. Assets

Link to assets:

• [ ] Dataset
• [ ] Code
• [ ] Protocol
• [x] Other: Complete dossier v1.0, supplied alongside this body. The materials are accessible at pinned commit 6ce0f55a458bd38ea86e5f54debdc1d3dfbd44a3 while PR #19 is pending.

IP notes / attribution: Iván Abril Palma credits Nelson Trasatti's discussion of 29 September 2026 for the motivating observation about agents contributing to trust specifications. The conversation with Larisa Ginosyan, Founder and CEO of MIHR (Machine Intelligence Human Ratio), on 28 September 2026 motivated the labeling inquiry. These personal-conversation attributions, their limits and the separate public references are retained in dossier PC01/PC02. MIHR participation is optional.