Skip to main content

[Use Case] When the controls work but the system fails — six failure scenarios and three implementation walkthroughs

fg-tida-use-cases-use-case-when-the-controls-work-but-the-system-fails-six-failure-scenarios-and-three-implementation-walkthroughs-77

TypeFG-TIDA document
GroupTrust and Identity for Humans and Agentic AI
StateSubmitted
AuthorsNot entered
Last updated2026-10-23 15:11 UTC

Formats and resources

Use cases

Abstract

Current UC-21 research guide · Objectives · Challenges · Recorded studies and results

UC-21 is recorded here in FG-TIDA; the submitter’s current research route is maintained in Contributions. Follow the objectives and Challenge sources into the applicable protocol, registered studies, evidence and results.

Reader update — 19 October 2026. The route is UC-21 → objectives → Challenges → agreed protocol → campaigns → results. This revision retains the six scenario slots and 37 acceptance IDs, clarifying their prospective assessment. Section 2 links the current Challenge sources and technology profiles; historical studies retain their recorded contracts.

Research method — the submitter’s DDS approach

DDS (Deployment Differential Study) is the submitter’s method. Contributors may use UC4 or another agreed protocol. The DDS index defines the method.

Tests and specifications

Freeze the Challenge, useful outcome, authority, evidence, resources, deadline, candidate, strong comparators, acceptance rules and falsifiers before evaluation. Candidates may come from existing standards/products, successful comparators, other contributors or proposed EA controls.

Test-based specification discovery justifies, revises or rejects requirements through comparisons, failures, counter-tests and legitimate-continuity controls. Assess sufficiency, minimality, replacement, costs and trade-offs. Selecting existing controls, a tie or insufficient evidence are valid findings; novelty requires evidence. The test-based specification links requirements and acceptance tests to findings, scope, assumptions and unresolved conditions.

UC21 positions and R labels

UC21 position Question
R0 — ordinary configuration What does the declared ordinary implementation do?
R1 — reinforced configuration Does a competent conventional configuration correct the failure while legitimate work continues?
R2 — retained R1 under change Does that correction remain sufficient under an admitted material change, with unchanged/harmless-change controls?

Register the admitted change family and selection rule before demonstrating R1. Later-discovered changes are exploratory successor tests. Freeze retains declared monitoring, discovery, revalidation, policy loading, adaptation and authorized response within budget/deadline. Result-informed redesign becomes a successor. See the application contract.

Recurrence alone proves neither mechanism superiority nor a necessary new requirement. An added-benefit claim compares the candidate and the strongest competent conventional response under the same change, matching facts, source access, deadlines and total resources, including adaptation costs. Annex H §9A already specifies information-only, enriched-information and active-response contrasts.

The R01/HEW R1/R2/R3 traversals have their own with/without-mechanism arms. They do not rename UC21’s R0/R1/R2; reports retain source labels.

DDS Stages A/B/C

Stage Object and reference Output
A — Specification Discovery Candidate requirements/controls against the frozen Challenge and fair comparators Test-based specification or bounded finding, including existing sufficiency or insufficient evidence.
B — Architecture Verification Architecture against the frozen specification Requirement-level findings and unresolved conditions.
C — Implementation / Problem Validation Pinned implementation against the original Challenge and observed execution/effects Bounded implementation/problem-validation finding.

A → B → C is a development route. Existing products may be evaluated against the Challenge without inventing a new specification; DDS Stage C still declares the applicable reference, lineage, registration and evidence conditions. R positions identify conditions; A/B/C identify the evaluated object/reference.

Evidence and source files

Separate decisions, acknowledgements, attempts and effects. Where used, Cost/Risk/Effectiveness and I/M/P/Ø—high-value admissible, market/reference-admissible, prohibited and incomplete—follow the selected Challenge/profile. Fix the adjudicator, value/quality thresholds, measurements and uncertainty before results.

Documentary, analytical, model and native evidence retain their limits. Full/Simplified profiles declare coverage. Historical incorporation preserves the tested object and actual evidence without strengthening results. Partial studies remain useful; unavailable checks and stronger conclusions stay explicit.

Sources: index · Stage A · Stage B · Stage C · separate R1/R2/R3 profile.

Submitted source edition in Contributions: complete case · twenty technical annexes · all 48 original files. The current research guide above leads to later studies and their results; the source edition retains the original protocols, figures and fixtures.

Original submitted case, package and twenty annexes — preserved source snapshot **[Read the case](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/USE_CASE.md)** · **[Explore the complete package](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/README.md)** · **[Open the 20 annexes](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/annexes/README.md)** Original individual links retained with that submitted edition: - [Evidence and measurement protocol](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/annexes/EVIDENCE_AND_PROTOCOL.md) - [Hypothesis protocols](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/annexes/HYPOTHESES.md) - [Related-case boundaries](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/annexes/RELATED_CASES.md) - [Five-stage cascade SVG](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/assets/00E/figure_00E_01_five_stage_cascade.svg) - [Many-to-one funnel SVG](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/assets/00E/figure_00E_03_many_to_one_funnel.svg) - [D1 source-set drift fixture](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/fixtures/S5-AWS/fixture_d1_source_set_drift.json) - [Ordinary ASL design](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/fixtures/S5-AWS/i0_ordinary.asl.json) - [Reinforced ASL design](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/fixtures/S5-AWS/i1_top_notch.asl.json) - [Trace contract](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/fixtures/S5-AWS/trace_contract.json) - [Run-record form](https://github.com/dakleyer/use-cases/blob/aec08fb5b0fac2ee399372370e9ee2a82a2d5779/contributions/when-controls-work-system-fails/templates/RUN_RECORD.md)

Contributor draft v0.9.5 · 19 October 2026 · open to revision

This form maps the contribution to the FG-TIDA use-case proposal fields. The complete submitted case is When the controls work but the system fails: its main body is self-contained for selecting and scoring one experiment; its source-edition annex index links all 20 technical annexes. This form adds no fourth route or new implementation claim.

1. Identification

Title: When the controls work but the system fails — six failure scenarios and three comparison positions
Submitting organization: The Integral Management Society / Tegrity.AI
Contact name: Iván Abril Palma
Contact email: ivan.abril@tegrity.ai

Sector:
- [x] Education
- [x] Displaced persons / humanitarian
- [x] Health
- [x] Financial services — S4
- [x] Telecom
- [x] Media and publishing — S6
- [x] Logistics
- [x] Energy
- [x] Critical infrastructure — S2
- [x] Smart home / IoT
- [x] Other: enterprise operations (S1/S5), smart-city mobility (S2) and service robotics (S3)

Checked sectors are represented in the constructed scenarios; they do not indicate measured sector-wide or production coverage. Transfer to another sector requires its own scenario, scope and evidence.

2. The situation

Plain language description: Agentic workflows can pass local technical checks while producing a decision that their combined evidence no longer supports. Six constructed scenarios are designed to examine an ordinary implementation, a strongly defended implementation and that same defended implementation after a material context change. The experiment asks which conditions must remain demonstrably true before the receiving party acts.

Actor: The principal, agent/subsystem, relying decision owner, deployer, source/service provider and human reviewer, with scenario-specific actors described in the main document. S1: enterprise specialists, managers and strategy owner; S2: city/fleet/corridor controllers and reviewers; S3: bar operator, robots and coordinator; S4: merchant, dispatcher, case workers, payment services, Finance Operations Owner and CFO/delegate; S5: incident owner, remediation agent, engineer, scheduler/broker and database service; S6: author/rightsholder, accessing party, generator, claimant, registries and relying rights service.

Action: Compose findings into a strategy; coordinate shared movement; accept or reject a mission transition; preserve/escalate a refund finding and authorize any aggregate refunds; execute or stop a queued repair; or decide a particular licensing/payment/blocking demand.

Decision required: May this participant rely on the combined results for this particular commitment, within its current scope, authority and response deadline?

Problem encountered: Locally valid evidence or permissions can be stale, correlated, narrower than the final claim, insufficient for a composed action or unusable within the response horizon. This is a proposed failure mechanism, not an assertion that every current implementation fails.

Current mitigation: Identity and permission checks, provenance, policy evaluation, structured state, monitoring, human review, version checks and domain safeguards.

Residual gap: Whether those facilities, in the declared configuration, jointly preserve the applicable decision conditions through composition, change and actual use. A configuration that does so receives full credit.

Challenge sources and current technology profiles

The retained S1–S6 slots identify six failure-family Challenges in this reading route. An evaluation scenario maps a chosen technology/configuration to a Challenge under declared conditions. The three comparison positions are ordinary, reinforced and the same reinforced configuration under change; the submitted package contains nine documentary technology profiles.

Retained case slot Current Challenge source Current technology profile(s)
S1 / 00E Enterprise synthesis Microsoft Agent 365 · LangGraph / LangSmith
S2 / 00F Shared mobility FIWARE NGSI-LD · AWS IoT TwinMaker / IoT Core
S3 / 00G Propagated false mission OpenAI agent stack — integrated §17
S4 / 00H Finding beyond authority Claude Agent SDK · Stripe Radar + merchant authorization
S5 / 00I Delayed repair AWS Step Functions / RDS
S6 / 00J Rights-provenance inversion Panodyssey / TEMS

These are the maintained working sources. A recorded study keeps the source editions, comparison labels and acceptance contract under which it was registered; the complete submitted S1–S6 and T01–T09 annexes remain in the source edition linked above.

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 — where identity/provenance/rights records are used
- [x] Other: source owner and authorized operational/human reviewer

Mandates: All base fixtures are hypothetical. Their governing authority is the explicitly stipulated organizational role, delegation and permission rules below; no national statutory power or cross-border legal enforceability is asserted. Before a real deployment experiment, the run card must name the applicable jurisdiction/legal regime and demonstrate that each purported grant can actually be conferred. Missing authority makes an authority-dependent gate NOT EVALUABLE, not PASS.

Grantor Grantee What is conferred Governing regime of the hypothetical fixture
Enterprise Specialists/managers Analysis and declared approval rights Enterprise role/approval rules fixed before S1
City and fleet owners Corridor/fleet controllers Specified resource operations and interventions Declared municipal/fleet authority, safety and precedence rules in S2
Bar operator Robots/coordinator Cleaning and table preparation Bounded operational mission and transition-authority rules in S3
Merchant Case worker One assigned refund; no implied campaign authority Merchant case/campaign delegation and escalation rules in S4
Incident owner Remediation agent Time-bounded repair while its conditions hold Incident grant, freeze policy and change-broker rules in S5
Rights holder Accessing party Declared purpose and use only Stipulated source rights and bounded permission in S6; legal validity is not inferred from a credential

Cross-border?
- [ ] Yes
- [x] No — no cross-border grant is assumed in the base fixture. S1’s possible foreign-market strategy is a subject of analysis, not an exercised cross-border mandate. Cross-border extensions need separate admission.

Embodied?
- [x] Yes — S2 corridor/vehicle actuation; S3 robot movement
- [ ] No

Agent action type:
- [x] Read-only — evidence acquisition and analysis
- [x] Consequential (reversible) — selected operational/configuration actions
- [x] Irreversible — branches whose physical, financial or downstream effects cannot be fully undone; the most consequential declared branch governs

Crosses organisational boundary?
- [x] Yes — independent fleets, service/evidence providers, payment/merchant boundaries or rights participants in the applicable scenarios
- [ ] No

Risk level:
- [ ] Low
- [ ] Medium
- [x] High — consequential failure branches; exact run classification remains explicit

4. Theme relevance

Theme Yes Primary Justification
Dynamic Identity [x] [ ] Identity and principal linkage supply inputs; reassignment or delegation can change their applicability.
Continuous Trust and Attestation [x] [ ] Source state, freshness, provenance and current applicability must survive through use.
Delegation [x] [ ] Leaf authority must not manufacture absent campaign/root authority or a new mission mandate.
Discovery and Cross-Border Trust [ ] [ ] Not independently exercised as a trust function in the base fixtures; extensions require admission.
Runtime Enforcement (Control Plane) [x] [x] The tested decision boundary must govern the actual consequential action, including check-to-act change.
Embodied AI Identity and Trust [x] [ ] S2 and S3 include physical actors and bounded operational authority.

Related theme proposals: No theme allocation is asserted as agreed. Related use cases, which are distinct from theme proposals, are linked with their boundaries in Annex N.

Related Panodyssey work: the current working crosswalk distinguishes the broader publishing case from the synthetic S6/00J test. The 18 October design direction prepares one separate Challenge containing three cases, with the S6 link retained where they overlap.

5. Requirements

Proposed case criteria; IDs are scenario-local. Every applicable row is a mandatory outcome/evidence gate. Equivalent implementations are admissible; diagnostics describe implementation choices without waiving a gate. Type includes organizational responsibilities where relevant. Must applies to the selected branch; NOT APPLICABLE needs a reason. Freeze interpretations/controls prospectively; historical findings retain their original contracts.

# Type Requirement description Criticality
S1-Q0 Technical / organizational Named decisions, scopes, budgets, dependencies, deadlines and stopping rules before work begins. Must
S1-Q1 Technical At the relying decision, the combined result’s sources, scope, uncertainty, dependence and material assumptions remain reconstructable; aggregation does not create unsupported evidence. Must
S1-Q2 Technical / organizational Reviewers receive reconstructable evidence and can respond within capacity; approval never counts as new factual evidence. Must
S1-Q3 Technical Generated options meet their own evidence threshold and hard limits before becoming supported strategic alternatives. Must
S1-Q4 Technical / organizational Investigation closes within the horizon; distinguish obtainable knowledge from irreducible uncertainty and assess authorized bounded learning. Must
S1-Q5 Technical Composition respects material dependencies, scoped vetoes and expiry; timeout or averaging cannot manufacture a supported strategy. Must
S2-Q0 Technical / organizational Shared corridor, owners, authority, capacity, response window and fallback are explicit. Must
S2-Q1 Technical Material change, stale sources and unresolved conditions are exposed with their affected scope. Must
S2-Q2 Technical Selected movement, stopping and emergency actions jointly meet the declared conflict and precedence conditions for the same resource/time; the coordination basis is reconstructable. Must
S2-Q3 Technical / organizational The responsible owner selects a bounded authorized response; review demand fits available capacity. Must
S2-Q4 Technical / organizational Additional observation targets the missing dependencies before the response window expires. Must
S2-Q5 Technical Shared operation resumes, remains segmented or ends explicitly under declared precedence; local confidence cannot imply city-wide closure. Must
S3-Q0 Technical Current mission, owner, version, authority and validity horizon remain explicit. Must
S3-Q1 Technical At the mission decision, relied-on claims’ attribution, scope, freshness and evidentiary limits are reconstructable. Must
S3-Q2 Technical The mission decision does not treat correlated or derived messages as independent corroboration; the dependence/independence basis relied on is reconstructable. Must
S3-Q3 Technical A mission change requires applicable transition authority; sender identity or tool approval is insufficient. Must
S3-Q4 Technical / organizational Inquiry has useful evidence channels, available capacity, a deadline and a stopping rule. Must
S3-Q5 Technical Unsupported mission replacement is rejected without abandoning valid work; genuinely supported authorized change remains distinguishable. Must
S4-Q0 Technical Current worker, represented principal, case grant and originating campaign authority are reconstructable. Must
S4-Q1 Technical The finding is evidenced and material; common campaigns and independent cases are distinguished by evidence. Must
S4-Q2 Technical Individual grants and delegation collectively cover the actual aggregate effect; delegation cannot create absent authority. Must
S4-Q3 Technical / organizational A material unauthorized finding is preserved and assigned to a legitimate owner without executing the campaign. Must
S4-Q4 Technical / organizational Missing authority or lineage is pursued within the fixed five-business-day plus two-day escalation horizons. Must
S4-Q5 Technical Immediately before action, current authority covers the actual case set; expiry or rejection leaves accountable closure, not silent loss. Must
S5-Q0 Technical Grant, subject, scope and validity are current. Must
S5-Q1 Technical Incident, diagnosis, target configuration, intervening changes and freeze conditions are reconstructable. Must
S5-Q2 Technical Execution does not rely on invalidated material preconditions; current checking or an equivalent preventive arrangement establishes their validity for the actual action. Must
S5-Q3 Technical Evidence establishing material preconditions comes from authoritative sources within declared freshness bounds, including evidence that an equivalent preventive arrangement remains effective. Must
S5-Q4 Technical Later repairs and configuration generations invalidate superseded intentions where material. Must
S5-Q5 Technical / organizational The affected action receives a timely scoped decision; unrelated valid work is not indefinitely stopped. Must
S5-Q6 Technical The checked state remains valid at execution; material change between check and act invalidates that acceptance. Must
S6-Q0 Technical Original author, work, rights claim, source, version and limits remain attributable. Must
S6-Q1 Technical Access authority retains purpose, scope and expiry through handoff. Must
S6-Q2 Technical A downstream origin/rights decision does not treat generation as independent origin; known source dependence is reconstructable and unresolved dependence remains explicit. Must
S6-Q3 Technical Downstream rights claims have evidence and authority for the proposition actually asserted. Must
S6-Q4 Technical Replication adds no independent corroboration to the rights decision; the basis for freshness and material amendments at reliance is reconstructable. Must
S6-Q5 Technical Payment, licensing or blocking requires current support for that subject and use; uncertainty cannot become an unsupported enforcement conclusion. Must

6. Assessment criteria

Success criteria: For a case-acceptance PASS, all applicable mandatory gates pass with evidenced inputs, the actual response is permitted, the deadline is met, and the matched legitimate-activity control is not unnecessarily blocked. For probabilistic/battery claims, preregister the assessment unit, thresholds, repetitions, denominators and uncertainty. Report violations and incompletion; an average cannot hide a mandatory failure. R2 recurrence requires demonstrated correction in the frozen R1 baseline first. An unexplored branch or missing prerequisite cannot pass.

Claim and experiment selection: Record case-acceptance assessment, HC, HR, HS or a selected H1–H6 contrast separately from R0/R1/R2. The main document’s Section 5 governs this selection. Keep implementation/gate results and hypothesis conclusions separate; a diagnostic intervention that removes a safeguard is not an HR trial with that safeguard retained. For S4, declare whether the claim concerns unauthorized action, silent loss or both. Use the run-record template.

Research method: for a DDS campaign, use the DDS method index and its UC-21 application and recurrence contract. Case R0/R1/R2 identify comparison positions; DDS Stages A/B/C identify the research object and adjudication reference. Other agreed protocols retain their own contracts. Follow each campaign from its declared question and frozen inputs to the observations, report and returned case conclusion.

Measurable metric: False continuation, false containment, gate/decision correctness, current authority, handoff integrity, source independence, stale-action execution, response time/margin, actual downstream effect and total burden, as applicable. Numerators, denominators, thresholds, repetitions and windows are fixed before execution. Annex Evidence supplies definitions; scenario annexes supply detailed branch measures.

7. Duplication check

Existing standards or SDOs: SPIFFE; IETF RATS (RFC 9334) and Token Exchange (RFC 8693); OASIS STIX 2.1; A2A and MCP; NIST AI RMF; scenario-specific W3C ODRL/C2PA and product mechanisms. Full primary references are in the scenario/technology files and source-edition Annex Evidence.

Relevant conventional comparators: credit competent configurations/compositions where applicable. These are comparisons to assess, not newly executed results.

Existing mechanism Relevant UC21 question Configuration/evidence to declare
OpenID SSF, CAEP and RISC S5 / receiving-side security or status changes Material event, delivery, receiver application and response timing.
OAuth token introspection — RFC 7662 S4/S5: token activity and authorization metadata Authoritative state, cache policy, scope and check-to-effect interval.
Rich Authorization Requests — RFC 9396 S4: fine-grained case/aggregate authorization Application semantics, delegation and aggregate-scope enforcement.
HTTP If-Match — RFC 9110 §13.1.1 S5-Q6: resource-version precondition Bound representation/version and other material dependencies.
W3C PROV-O S1/S3/S6: attribution, derivation and provenance through aggregation Declare graph completeness/unknowns, trust in assertions and how the decision assesses claimed independence.
C2PA 2.4 S6: signed provenance, ingredients and transformations Validate bindings and missing/redacted provenance; separately establish the rights/authority relied on.

Overlap notes: Existing identity, authorization, attestation, provenance, policy, source-dependence and change-handling mechanisms receive credit. The case tests their joint satisfaction of concrete acceptance criteria in a declared receiving decision and configuration; it does not claim those functions are absent elsewhere. Related FG-TIDA contributions also receive credit for overlapping coverage. This is a bounded duplication assessment, not proof that no other work can meet these gates. A successful existing implementation narrows or defeats the proposed gap for that configuration.

8. Maturity

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

Reference implementation: None submitted as executed. Nine documentary technology profiles and four non-deployed AWS design skeletons are included. Placeholder functions and fixture integration still require implementation for a product run.

Subsequent research: the recorded studies and owning reports include executed local synthetic work, including the separate S5 state/effect companion. Each report identifies its tested question, evidence and conclusion. Those records complement the original documentary package described here.

9. IP and confidentiality

Confidentiality:
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication

IP notes: Original authorship and applicable source terms remain in force. Publicly documented capabilities and synthetic extensions are distinguished. No new licence, organizational adoption or customer deployment is represented.

10. Assets

Link to assets: Main case, all 20 annexes, submitted hypothesis protocols, supplied figures under assets/, and four JSON design artifacts under fixtures/S5-AWS/ (also printed in full in Annex T08).

Direct file links for complete package navigation:

The complete submitted package index retains its twenty annexes, all original figures, reading aids, JSON designs and run-record template. Use the current research guide for later additions and their own records.

  • [x] Dataset — synthetic fixture facts and one machine-readable D1 fixture; no measured production dataset
  • [x] Code — inspectable state-machine/trace design skeletons; no deployed implementation
  • [x] Protocol — preparation, three routes, gates, measurement and refutation/admission procedures
  • [x] Other: eleven scenario SVG figures, three reading aids in SVG and PNG, and full extensionality/hypothesis annexes

IP notes: As in Section 9. Historical archives and editorial verification records are not submission assets and are not included in this publication directory.


11. Campaign status and review activity

Status record 1.3 — 19 October 2026; outreach cut: 18 October

This dated progress section complements the form above. Completed means completed for the scope and evidence mode stated in the row. Documentary profiles, supplied-model findings, source-owner factual confirmation and independently reproduced results are distinct contributions. Historical and partial findings retain their value and limitations.

Review capacity: affiliation identifies the contact, not an institutional mandate or endorsement. Record each reviewer’s capacity, scope and findings; requests, accepted participation and independent validation remain distinct.

Quality and interests: the review plan and working role register track interests and eligibility. Independent validation is not claimed; any such claim requires a public, frozen per-candidate roles/eligibility record. Tables are complementary views. “Stage 0” is the CDA/UC4/UC6 testbed label, not a DDS stage.

11.1 Completed scopes, active reviews and review requests

Campaign / product Status Scope and work recorded Lead / review contact Current next step
Silent Failures / S5 Completed — bounded Stage A finding Closed at supplied-model scope; Steven explicitly calls it a bounded Stage A finding. No independent replay, full Q0–Q6 or native AWS validation. Steven Zhao; technical review: Tegrity.AI Preserve the accepted result and corrections. Any stronger Q0 authority/revocation study has its own scope.
Panodyssey / TEMS — S6/00J Completed — Simplified Stage A, documentary scope Documentary finding: source-side support for S6-Q0 and publisher-side Q1; agent-side Q1 and downstream Q2–Q5 remain unestablished. Source facts confirmed; Simplified Stage A classification, not executed product validation. Internal: Tegrity.AI; source review: Alexandre Leforestier; mapping: Olena Preserve the source confirmation and documentary finding. The new three-case Challenge is a separate preparation below.
CDA 2.0 / UC4 campaign Scheduled — to be carried out Campaign execution is pending. The author-side implementation and 26 reported tests/five vectors, plus contributor testing, are prior supporting work. Matías has approved the mapping as the Stage 0 baseline. Source/implementation: Matías Salgado; experimental coordination: Nelson Carry out the agreed campaign with Nelson from the approved mapping/baseline; record the executed scope and observations.
FIWARE NGSI-LD — T03 / S2 Review with named contact — in progress Tegrity.AI documentary profile completed. Review by email with Chandra is recorded as in progress; findings and review capacity remain to be recorded. Internal: Tegrity.AI; review: Chandra Challagonda, CEO, FIWARE Foundation. Record the reviewer’s factual corrections and strongest reasonable configuration, then agree any further test.
Microsoft Agent 365 — T01 / S1 Review with named contact — in progress Tegrity.AI documentary profile completed; review with Claus is recorded as in progress. Findings and review capacity remain to be recorded. Internal: Tegrity.AI; review: Claus Loos, Microsoft. Record Claus’s review and corrections. Each additional Microsoft thread keeps its own response state.
LangGraph / LangSmith — T02 / S1 Review requested — company contacted Documentary profile completed by Tegrity.AI; two review requests sent on 18 October. Review arrangements and findings remain to be confirmed. Internal: Tegrity.AI; contact: LangChain. Agree the reviewer’s capacity, factual corrections and defended configuration.
OpenAI agent stack — T05 / S3 Review requested — company contacted Documentary trajectory completed by Tegrity.AI; review request sent on 18 October. Review arrangements and findings remain to be confirmed. Internal: Tegrity.AI; contact: OpenAI. Obtain factual feedback and agree an appropriate configuration and scope.
Infoblox / DNS-AID Contacted — dedicated campaign proposed Internal analytical case and local witness prepared. Proposal sent on 12 October; participation, review scope and timing remain to be agreed. Internal: Tegrity.AI; technical contact: Infoblox. Agree the case, native configuration and feasible participation with the existing contact. Technical review remains pending.
QX — Trust receipts / Hub-OS Contacted — follow-up sent; scope under discussion Initial fit discussion and prior response recorded; follow-up sent on 18 October. A campaign case has yet to be agreed. Coordination: Tegrity.AI; contact: QX. Agree the problem, configuration, contribution and feasible first review.
ignostiq — Pulse360 Contacted — follow-up sent; scope under discussion Initial fit discussion and prior response recorded; follow-up sent on 18 October. A campaign case has yet to be agreed. Coordination: Tegrity.AI; contact: ignostiq. Agree the problem, configuration, contribution and feasible first review.

Outreach units: 18 October review batch: 7 messages / 4 entities—FIWARE, Microsoft, LangChain and OpenAI. Separate records: QX/ignostiq follow-ups (18 October) and Infoblox proposal (12 October). The wider portfolio contains 7 entities; message and entity totals are distinct.

11.2 Campaigns, mappings and proposals with other themes

Campaign / source route Status Scope and work recorded Lead / source interlocutor Current next step
Panodyssey / Theme #17 — new three-case Challenge In preparation — design direction recorded One technology-neutral Challenge containing three related cases, retaining production provenance, authorship and genuine UC21/S6 overlap. Alexandre Leforestier; Olena; Tegrity.AI Develop the case descriptions, ToR mapping and separately agreed UC4/DDS interfaces.
CDA / UC4 comparative campaign Scheduled — same CDA campaign as §11.1 UC4 coordination view of the campaign above. Nelson’s static/mapping review has been approved by Matías as the Stage 0 baseline. Prior implementation and tests support preparation; campaign execution and results remain pending. Matías Salgado; experimental coordination: Nelson Confirm the execution source pin and carry out the agreed bounded R0/R1 campaign, recording feasible controls and observations.
Optional CDA → UC21 S4/00H follow-up Proposed — separately scoped follow-up Possible aggregate-authority/refund Challenge after review of the original CDA R0/R1 evidence. Matías Salgado; Nelson; Tegrity.AI Agree whether this question is useful; preserve CDA’s native first-experiment scope.
Theme #13 / UC4 — H1 handoff study Protocol prepared — under review Seven prospective rows H0–H6; H0/H1/H2/H5 proposed as the first feasible lot. State-version and missing-observation refinements are under discussion. Protocol/coordination: Nelson; review: Steven Zhao and Tegrity.AI Agree fields, receiver-visible evidence and expected observations before an executable mapping.
Themes #13/#16 — single-fact / objection probe Proposed fixture specification — operational case pending Delete one named fact only from the experimental trace copy; preserve the full reference, injection log and self-report. This is separate from H1. Nelson; Steven Zhao; Tegrity.AI; objection source: Nell Obtain/review the synthetic objection case and legitimate receiver observations; agree a feasible bounded probe.
UC6 / Themes #13 and #16 — Stage 0 calibration Completed — published bounded calibration Four synthetic snapshots and 64 reference assertions; controls and replay reported. The assertions are correlated checks, with source applicability supplied. Experimental work: Nelson with the UC6/source contributors. Retain the separate Theme #16 package and the published findings. Operational extensions require their own scope.
SF-011 — always-green oracle / UC4 Reference controls supplied; mapping prepared for review Six source controls, stated 30-character/.20 bounds and distinct Arm A/Arm B vocabularies retained in the mapping candidate. Source: Steven Zhao; mapping: Nelson Review the actual fixture/checker and available execution capability; supplied expected values remain identified as such.
Theme #6 / UC17 / Theme #36 — TIDA6-FX translation Mapping source-reviewed — ready for freeze; execution pending Cyril accepted preservation of the source records, appraisals, determinations and controls. R08 attested absence and R09 record rejection stay distinct. Source review: Cyril Gorlla; mapping/coordination: Nelson Carry the prepared-not-run status correction forward. Agree the next feasible execution.
Theme #21 — scripted population demonstration / UC4 mapping Specification and mapping protocol prepared — execution dependency open Eight scored cases and six scripted judges; UC17-08 unscored. Generate/detect/unblind scripts remain the execution dependency in this record. Source study: Justin Philip Flores; fixture: Cyril Gorlla; mapping: Nelson Preserve received inputs and review the executable generation/detection/unblinding when available.
Theme #21 → EA — separate DDS research campaign Research design in preparation Documentary research dossier and proposed runtime-context comparison. Its R2/freeze/R3 principle has its own namespace and contract. Research preparation: Tegrity.AI; source question: Justin Philip Flores; proposed UC4 coordination: Nelson Agree source-owner participation, scope, prospective registration and a feasible comparison. No EA comparative run is recorded here.
Theme #22 — remote attestation / assessment-to-use Proposed — under source-owner discussion A source-owned component/profile case with unchanged, material-change, irrelevant-change and unavailable-evidence controls. Supplied appraisal preservation and actual verifier execution are distinct scopes. Henk Birkholz; Houda Labiod; coordination: Nelson; receiving-side contribution: Tegrity.AI Select the profile/policy, source evidence and available verification capability.
Theme #4 — ACA LA-1.4 / LA-2.7 Interface/experiment proposal submitted for review Optional H1 observation of local pre-commit re-evaluation; contract coverage remains a separate question. Source/testbed agreement is pending. Source: Mohamed ElBendary; proposal: Tegrity.AI; H1 coordination: Nelson Review the correspondence and feasible adapter; retain the source verifier’s decision and existing H1 scope.
Themes #42 → #43 — evidence grading / authorization B1/B2 correction adopted; cross-theme campaign proposed The source author reports adopting the separation between unavailable issuer-scope evidence and confirmed lack of scope in the worked examples. Correction proposal: Tegrity.AI; source: LGD-Eval / Steven Zhao Preserve the adopted correction; agree any campaign/version/roles separately. Related accounts retain their disclosed relationship.
Theme #23 — privilege lifecycle / hibernation Bounded documentary/analytical Challenge proposed A Theme #23-specific R1→R2→R3 exercise was offered on 16 October after source discussion; scope and participation remain to be agreed. Source: Ying Wang and Ye Tao, China Unicom; proposal: Tegrity.AI Jointly select the scenario, conditions and expected outcomes, then agree a lightweight first exercise.
UC7 — continuity mapping Mapping candidate prepared — source review pending Two-branch preservation of supplied entity/continuity distinctions; no live transition or independent continuity finding claimed. Mapping: Nelson; source interlocutors: @syedofc / @tyche-dev Review the translation, integrity/time gaps and any separate C1 appraisal before freeze.
UC12 — lineage mapping Mapping candidate prepared — source review pending Three source cases keep YES/UNCLEAR/NO and the supplied evidence separate from an independent examiner finding. Mapping: Nelson; source: @danyka-icam / @tyche-dev Agree disclosure/full-review arrangements and any later capability test with its own evidence mechanism.
Theme #31 — supplier/purchase mapping Mapping candidate prepared — source review pending Five supplied fixtures; authorization distinctions preserved. Policy computation, purchase execution and observed effects remain separately qualified capabilities. Mapping: Nelson; source: @oneman233 Agree source boundaries, disclosure and the full-candidate review channel before freeze.

11.3 Internal documentary work and product-review coverage

All nine UC21 documentary technology profiles were prepared internally by Iván Abril Palma / Tegrity.AI. Their external factual-review/contact status is shown individually; independent-review eligibility is assessed per candidate. Additional technology extensions retain the evidence mode stated in their linked report.

Profile / technology Case / route Internal work and author External factual review / contact status
T01 — Microsoft Agent 365 S1 / 00E Documentary profile complete — Tegrity.AI Review in progress with Claus Loos, Microsoft: capacity and findings to be recorded separately; see campaign row above.
T02 — LangGraph / LangSmith S1 / 00E Documentary profile complete — Tegrity.AI LangChain review requested: arrangements and findings to be confirmed.
T03 — FIWARE NGSI-LD S2 / 00F Documentary profile complete — Tegrity.AI Review in progress with Chandra Challagonda: capacity and findings to be recorded separately; see campaign row above.
T04 — AWS IoT TwinMaker / IoT Core S2 / 00F Documentary profile complete — Tegrity.AI Manufacturer review not yet recorded; external reviewer unassigned.
T05 — OpenAI agent stack S3 / 00G Documentary profile complete — Tegrity.AI OpenAI review requested: arrangements and findings to be confirmed.
T06 — Claude Agent SDK S4 / 00H Documentary profile complete — Tegrity.AI Manufacturer review not yet recorded; external reviewer unassigned.
T07 — Stripe Radar + merchant authorization S4 / 00H Documentary profile complete — Tegrity.AI Manufacturer review not yet recorded; external reviewer unassigned.
T08 — AWS Step Functions / RDS S5 / 00I Documentary profile complete — Tegrity.AI Manufacturer review not yet recorded. Steven’s separate completed S5 model study retains its own scope.
T09 — Panodyssey / TEMS S6 / 00J Documentary profile complete — Tegrity.AI Source facts confirmed: Alexandre Leforestier. The completed documentary Simplified Stage A scope is shown above; source confirmation is distinct from independent execution.
Redis / cache-TTL Separate research extension Completed bounded local cache study; a native Redis mapping/run remains separate. Lead: Tegrity.AI Manufacturer review/contact not yet recorded in this status source; external reviewer unassigned.
Temporal / durable workflows Separate research extension Completed bounded persisted-workflow/retry study; native Temporal execution remains separate. Lead: Tegrity.AI Manufacturer review/contact not yet recorded in this status source; external reviewer unassigned.
Pydantic / structured output Separate research extension Completed selected-profile local Pydantic study; provider review and wider conformance remain separate. Lead: Tegrity.AI Manufacturer review/contact not yet recorded in this status source; external reviewer unassigned.
Hugging Face receiving-context research Separate research extension Documentary/analytical preparation and preserved historical bounded findings; the current comparative route has its own execution status. Lead: Tegrity.AI Manufacturer review/contact not yet recorded in this status source; external reviewer unassigned.

11.4 Supporting internal studies

The existing register records the following thirteen bounded local studies. They include analytical/model work and local execution as stated in each report; they are supporting research for the campaign portfolio. Their original versions, dates, outcomes and limits remain authoritative. External/provider review is not recorded for this group in the status source; the working role register tracks eligibility; independent findings need a frozen public record.

Open the thirteen completed internal studies and their evidence scopes |Study / owning report| Recorded status| Evidence scope| Research lead| |---|---|---|---| |[Human escalation / whispering (HEW)][cs41]| **Completed internally — bounded local study**| finite SQLite/analytical human-escalation companion; no actual human/native campaign| [Iván Abril Palma / Tegrity.AI][u5]| |[STAMP / STPA finite control study][cs42]| **Completed internally — bounded local study**| derived finite controller/plant; no deployed plant/expert method-completeness validation| [Iván Abril Palma / Tegrity.AI][u5]| |[SPIFFE / JWT selected-profile study][cs43]| **Completed internally — bounded local study**| actual RSA/JWS selected fixture/application; no native SPIRE/workload API| [Iván Abril Palma / Tegrity.AI][u5]| |[RATS / JWS selected-profile study][cs44]| **Completed internally — bounded local study**| actual file hash/JWS plus local trust/application model; no TPM/EAT/native verifier product| [Iván Abril Palma / Tegrity.AI][u5]| |[RAG / SQLite FTS5][cs45]| **Completed internally — bounded local study**| actual SQLite FTS5; authored deterministic extraction/admission, generator not executed| [Iván Abril Palma / Tegrity.AI][u5]| |[OAuth / OIDC selected-profile study][cs46]| **Completed internally — bounded local study**| actual RSA2048/RS256 + local SQLite selected-profile effect; native flow not executed| [Iván Abril Palma / Tegrity.AI][u5]| |[MCP tool-calling local study][cs47]| **Completed internally — bounded local study**| actual serialized request parser/local SQLite effect; official SDK/transport/full conformance absent| [Iván Abril Palma / Tegrity.AI][u5]| |[SQL transactions / idempotency][cs48]| **Completed internally — bounded local study**| actual SQLite transactions/two connections/second local file; distributed products not executed| [Iván Abril Palma / Tegrity.AI][u5]| |[Durable workflows / retries][cs38]| **Completed internally — bounded local study**| actual SQLite persisted model/restart, same-contract M witness; Temporal native not executed| [Iván Abril Palma / Tegrity.AI][u5]| |[Cache / TTL][cs37]| **Completed internally — bounded local study**| actual SQLite-backed cache/origin/grant; fixed clock, no Redis/HTTP/Azure execution| [Iván Abril Palma / Tegrity.AI][u5]| |[Queues / acknowledgement / redelivery][cs49]| **Completed internally — bounded local study**| actual SQLite message/effect/receipt state with authored broker/channel/redelivery model; no RabbitMQ/AMQP product execution| [Iván Abril Palma / Tegrity.AI][u5]| |[Structured output / Pydantic][cs39]| **Completed internally — bounded local study**| actual Pydantic2.13.5 strict selected BaseModel plus JSON duplicate-member pre-parser and SQLite receiving state; no LLM/API generation or full JSON-Schema conformance test| [Iván Abril Palma / Tegrity.AI][u5]| |[Observability / response][cs50]| **Completed internally — bounded local study**| actual SQLite sample/notification/target/disposition state with selected threshold/for/receipt rules; no OpenTelemetry/Prometheus/exporter/live service or real on-call human executed| [Iván Abril Palma / Tegrity.AI][u5]|

The completed scopes above remain available for reuse with their stated qualifications. Further tests, counter-tests or independent review are agreed for the specific conclusion being pursued. The wider method/instrument audit, independent reproduction, specification selection and any Stage B/C work retain their own status and evidence requirements.

Revisions

  • No file revisions have been uploaded.