From Field Practice to Pre-Standardization: An Extensible Case-Study Framework

A worked application to delegated authority under context change in ITU-T FG-TIDA

Tegrity.AI · Working paper v0.1 · 15 September 2026

Abstract

Field systems are a valuable source of architectural knowledge, but their details rarely transfer unchanged to another sector or to a standards group. Conversely, a standards discussion can become too abstract to expose whether proposed requirements survive real operating conditions. This paper proposes a deliberately small, boundedly extensible case-study framework for crossing that gap. A documented operating system is examined for its actors, constraints, decisions, interventions and evidence; these are distilled into a minimum case; the case is extended only while its core distinctions remain intact; and stable case facts become a common surface for technical challenges. Each challenge is traced to a group's Terms of Reference (ToR) and then developed into use cases, tests and evidence obligations by the relevant working groups or work packages. The resulting findings return to field design and deployment. The accompanying annex shows how the publicly available Delegated Authority OS under Context Change package applies this framework to FG-TIDA. It is an example of pre-standardization working material, not an adopted ITU model or a validated implementation.

1. Why begin in the field?

The methodological question is not whether a field system can be relabelled as a standard. It cannot. The question is whether enough of its operating problem, architectural discipline and evidence can be retained to construct a small reference case that other practitioners and pre-standardization groups can test.

The historical xSeil system offers such a starting point. Developed for a tourism-transport operation in 2016–2017, it combined service parameters, scenario-dependent planning, reservation and fleet integration, route-sheet generation, monitoring and reassignment. The surviving evidence is unusually useful: requirements, source code, Git history, issues, validation correspondence, reservation records and executed route sheets make it possible to compare the intended architecture with implementation and operating artifacts. It was a pre-agentic expert logistics system, not an agentic-AI platform or an implementation of a later research label. The xSeil provenance and code register documents this source trail; the 2026 MSCA working paper interprets selected properties retrospectively rather than claiming that MSCA was specified in 2017.

The later JubAp.eu Mobility OS proposition shows the continuing practitioner route: a historical coordination core, an orchestration add-on and a regime-awareness research workstream are described at different maturity levels. That page is useful evidence of a continuing field-to-product trajectory, not proof that the whole proposed system, or MSCA, has been experimentally validated in a city. Keeping those grades of evidence distinct is essential to a credible research abstraction.

The field record contributes three things an abstract thought experiment cannot supply alone: realistic scarcity and commitments; explicit operational decisions and corrective actions; and evidence about how imperfect information, deadlines and human roles affect execution. The abstraction should preserve these pressures while discarding sector-specific details that are not needed for the question being tested.

2. A minimum model, not a miniature copy of the system

The Minimum Sufficient Control Architecture (MSCA) uses three architectural dimensions as one distillation lens: C, the scope of actors or flows that can be coordinated or legitimately influenced; P, the effective interventions available; and M, the means to observe, communicate, interoperate and act. They are dimensions of an architecture, not three mandatory software components. A candidate configuration is meaningful only against declared outcomes, mandatory constraints and operating conditions. The xSeil analysis makes these distinctions inspectable without treating a good planning score as proof of effective control.

The FG-TIDA example takes another step. It does not simply rename C/P/M as three identity components. Its minimal mobility case retains three readable private-side concerns—commitment reliability, autonomy and economic outcome—and three public-side concerns—system efficiency, externalities and valid policy commitments. These small sets make conflicts visible. Authority, delegation, evidence and action-time determination are then represented explicitly. The relation to MSCA is methodological: choose a small set of dimensions sufficient to expose the operational seam, state what each dimension means, and do not mistake an objective, preference or interoperability capability for permission to act. Annex I records the concrete TIDA instantiation.

The minimum case has to be readable to more than its designers. A citizen should understand the consequence of a commitment; an implementer should distinguish the principal, role, agent, grant and policy; and a reviewer should identify which facts changed before an action. This is why a case is preferable here to opening with a complete reference architecture. It can reveal missing interfaces without pretending to prescribe every implementation.

3. Bounded vertical and horizontal extensibility

A minimum case would have little research value if it worked only for its original example. It would lose credibility if every later situation were forced into it. Extensibility must therefore be tested, not asserted.

Vertical extension changes scale. Upward, a citizen and municipality can be joined by providers, transport operators, employers, infrastructure owners, public authorities and chains of delegated agents. Downward, the same structural question can be reduced to a private factory or even one production cell: a worker or technical agent acts within a bounded envelope while production, maintenance, safety and quality roles retain different authority. Horizontal extension changes the service domain without necessarily changing scale: appointments, hospital resources, school rooms, compute capacity or logistics loads can replace mobility. Annex II gives these as controlled extension tests, not additions to the committed base case.

The portability test is semantic. Across a variant, a principal must remain the source of an interest or mandate; a role must remain bounded; an agent must act under a grant rather than acquire authority by convenience; a preference must not become a permission; and a commitment must remain identifiable at the point where context may affect its standing. If a new situation cannot be represented by adding actors, roles, grants, constraints or commitments without redefining these terms, the extension has reached a boundary. A different case is then the honest result. Portability is substantial but not infinite.

4. The challenge as the basic unit of pre-standardization

The important transition is not from one case study directly to an adopted standard. It is from field evidence to a stable case, and from that case to challenge units that groups can examine under a common set of facts.

A challenge states a question that an architecture or requirement must answer at a specific seam: for example, whether a grant remains applicable at action time, whether subdelegation preserves limits, or whether human oversight is operationally available before a deadline. It is neither a feature request nor a demand that one working group solve the entire ecosystem. Its usefulness comes from a testable boundary and explicit evidence.

For a definitive challenge unit, the following compact record is proposed:

The published FG-TIDA Annex III currently presents S1–S14 as challenge questions, not fourteen completed validation protocols. It explicitly leaves open whether a definitive version should turn each into a one-page unit with requirements, test conditions, evidence and criteria. The table above is a proposed way to make the author's broader framework operational; it is not an agreed FG-TIDA template.

5. Traceability, use cases and the return path

Terms of Reference keep the case from drifting into an attractive but unrelated problem. Each challenge should have a selective, many-to-many ToR mapping, not a claim that the case covers an entire institutional mandate. FG-TIDA's official ToR, SG17 TD 295-PLEN, and the package's Annex IV mapping provide that check for the worked example. The mapping itself must be refreshed against the live institutional text before formal use.

Use cases are the next, more concrete layer. A WG or WP can take an in-scope challenge and specify actors, initial authority, a trigger, observations, possible decisions, failure modes and evidence required for a pass. Several use cases may exercise one challenge; one use case may expose interfaces between several groups. The challenge remains the common unit so that different use cases do not quietly change the underlying question. A claimed solution should be checked against the same frozen case facts, then against controlled variants where its stated scope permits. These detailed group-owned use cases and validation results have not yet been produced by this public package.

record   := inspect(field_evidence, provenance, operating_limits)
candidate:= distill(record, actors, constraints, decisions, interventions)
if not intelligible(candidate) or not bounded(candidate): stop
variants := extend_only_while_core_terms_keep_their_meaning(candidate)
case_v1  := freeze_after_review(candidate, regime, provenance)
for challenge in expose_questions(case_v1, variants):
    anchor := map_selectively_to_TOR(challenge)
    if anchor is absent: revise_or_exclude(challenge)
    else: WG_or_WP_develops_use_cases_and_evidence_tests(challenge)
record_passes_failures_and_limits_under_unchanged_case_facts()
return_test_findings_to_bounded_field_design()

The loop closes only when results change practitioner decisions. A failed challenge may identify a missing status interface, a stale observation, an impossible human-response window or an authority conflict not represented in an existing deployment. A pass, by contrast, is evidence only within the tested facts and conditions. It can inform a field pilot, a component revision or a new evaluation plan; it is not automatic production authorization. This is how field practice informs research and pre-standardization, and how pre-standardization returns more precise questions, interfaces and evidence obligations to the field.

6. What this framework does and does not claim

This paper proposes a case-study-to-challenge method. It is not a universal agentic-system ontology, a claim that a single mobility case represents every service, or a declaration that an ITU standard already exists. xSeil demonstrates a documented field origin, not agentic-AI conformance; MSCA is a retrospective architectural interpretation and independent research proposal; JubAp.eu Mobility records a staged practitioner trajectory; and the FG-TIDA package is public collaborative working material. Each plays a different evidentiary role.

Three decisions are especially important before any formalized release: deliberately freeze a numbered base case after its design conditions are met; settle the level of specification expected of each challenge; and have the relevant groups develop use cases and tests without silently revising the frozen facts. At that point a portable reference model can be tested for pre-standardization value. Institutional agreement, validation and formal adoption remain separate events.

Annex A. Worked application: Delegated Authority OS under Context Change for FG-TIDA

A.1. Package, purpose and status

The public FG-TIDA working package comprises a README, a main pre-freeze structure note and five annexes. Its purpose is a small, understandable mobility case that existing FG-TIDA themes could test once its facts are frozen. It is not proposed as a new monolithic architecture, a compulsory separate workstream or a universal model. The README calls it a public pre-freeze working package and explicitly disclaims FG-TIDA/ITU adoption, endorsement, validation, agenda inclusion or incorporation into an ITU-T deliverable. “OS” in the case means operating logic or coordination architecture for delegated-authority determinations, not a software product or prescribed Smart City operating system.

The main note proposes three ideal pre-freeze conditions for a shared case, not agreed FG-TIDA eligibility rules: D1, multi-audience intelligibility and concreteness; D2, minimality with bounded extensibility; and D3, demonstrable ToR fit without drifting into city optimization or policy design. A fourth, “+1” case fact is the governing legal regime when the case requires mandate standing, revocation or action-time validity determinations. One declared regime can be enough; multijurisdictionality is not mandatory. These conditions are deliberately separated from the post-freeze solution challenges. The package proposes collaborative refinement, an explicit numbered freeze and then testing under stable facts; it does not state that the base case is already frozen.

A.2. The minimum mobility case

Imagine a citizen who must reach an appointment within an accepted window. Private decisions concern reliability, freedom to change or select a journey, and cost or compensation. Municipal concerns include shared capacity, external effects and valid access conditions. Neither side has a universal superior preference: a citizen's preference cannot waive a public policy, and a municipal objective is not itself authority to override the citizen's grant. Planning may compare a robotaxi, transit, a shared ride or compensated carpooling; the planning algorithm is context, not the FG-TIDA challenge.

The technical case distinguishes a principal, a bounded organizational or public role, an acting human or technical agent, and an agent instance. It also keeps a preference, policy, grant and decision distinct. A policy requires valid origin and applicability; a grant confers only bounded authority; a commitment records something whose standing may need renewed determination. This prevents a convenient plan or an optimizing objective from being mistaken for permission.

G1 and P1 preserve authority provenance; D1 and C1 preserve decision and commitment history; H1, if used, records a later intervention without overwriting them. A required assessment function—not necessarily a dedicated audit agent—classifies evidence as sufficient, insufficient or inconclusive and identifies which decision it supports. INDETERMINATE is not permission. A claimed human oversight path is viable only if its role is authorized, available, informed, competent and able to act inside the useful time window. The governing legal regime for mandate determinations remains a fact to declare before freezing this candidate case.

A.3. Extension and its stop boundary

The committed case is mobility/carpooling. An upward extension adds other principals, operators, infrastructure and authority chains; a downward extension tests a factory or production cell with management, maintenance, safety and quality roles; horizontal extensions test appointments, schools, hospital capacity, enterprise compute or logistics. Annex II does not convert these into additional base-case commitments. The question is whether principal, role, agent, authority, preference, policy, grant, commitment and decision retain their meanings. If a situation has no meaningful principal, no bounded authority relation or no identifiable decision/commitment point, it may require another frozen case rather than a forced extension.

A.4. The fourteen published solution challenges

Annex III frames the following as questions exposed by one stable case. A theme need test only the dimensions it claims to cover; passing one challenge is not proof of complete ToR coverage. The primary ToR anchors below reproduce Annex IV's selective mapping, rather than interpreting every clause as a requirement for every implementation.

S3 is phrased more broadly in Annex III (“regime, context, escalation and bounded escape path”) than in Annex IV's condensed mapping (“regime and context qualification”). That is an editorial interface to reconcile when defining a future version, not evidence that a specific challenge test has already been agreed. Annex III also expressly asks whether each definitive challenge should become a one-page validation unit, or remain a general orientation. The challenge-to-use-case step in this paper adopts the former as a proposed method, not as a FG-TIDA decision.

A.5. Selective ToR coverage and candidate use-case handoffs

The case-level anchor is FG-TIDA ToR 3.3 (use cases) and 4.1 (use cases and requirements analysis). Annex IV's many-to-many map is strongest around delegation, dynamic trust lifecycle, human oversight, runtime trust control, technical policy, interoperability, accountability and assessment. It deliberately excludes a claim to cover all FG-TIDA deliverables, substantive national digital-ID rules, general AI governance or every agentic protocol. These boundaries matter: a mobility planner or a city's policy owner may appear in the facts, but FG-TIDA is asked to test identity, trust, authority and their operational interfaces, not to solve transport optimization or write public policy.

The following use cases are illustrative derivatives proposed for later WG/WP development, not completed or adopted contents of the current GitHub package:

Each WG/WP would own the detailed semantics, test scenarios and pass criteria that actually fall within its mandate. Use-case IDs, group allocation, frozen input datasets, expected determinations and validation results are still to be developed. Silence, expired evidence, a failed command or an unavailable overseer should not be silently converted into success. A WG/WP's local pass must also be checked where its output meets another group's interface.

A.6. Adjacent standards and controlled research relevance

Annex V proposes comparison points, not dependencies imposed on the case or claims of collaboration. The stable base should be frozen first; adjacent groups could later test it unchanged, add a versioned bounded variant or propose a mapped challenge. Its documented map includes:

Annex V distinguishes stable standards from active work in progress and dates its reference review to 31 August 2026. Their status must be rechecked before formal external reuse. None of these adjacent references establishes that the corresponding group has adopted, tested or even discussed this case.

A.7. What the application has accomplished—and what remains

The package already supplies a coherent candidate: an intelligible mobility situation, a bounded extension analysis, S1–S14 questions, selective ToR traceability and a controlled adjacent-work map. It shows how practitioner-informed material can be made portable without erasing its evidence or pretending to be universal. Its unfinished steps are just as important: settle the exact frozen facts and declared governing regime; choose the challenge-unit specification level; derive WG/WP-owned use cases; agree required observations and validation criteria; and test both local requirements and cross-theme seams. Only then can a versioned case support reproducible comparison or a stronger pre-standardization claim.

The return to practice would take those results into a bounded field configuration or pilot and ask whether the identified authority, observation, oversight and response capabilities actually exist there. The public Mobility OS trajectory illustrates why that return path is relevant, but it is not represented here as a finished FG-TIDA implementation or proof of an adopted standard.

Sources and claim boundary

Primary worked-example sources: public FG-TIDA package and six canonical documents; official FG-TIDA Terms of Reference, SG17 TD 295-PLEN. Field and prior-research sources: xSeil provenance, delivery and code evidence; MSCA working paper; JubAp.eu Mobility OS. Direct document links above allow each condensed claim to be checked against its source. Institutional status, standards-work progress and implementation maturity are deliberately not inferred from conceptual relevance.