Document Status — Technical Verification Annex · Series: Ecosystem Awareness
This page is a technical verification annex to the public-facing foundation article. It is not the canonical source or a standalone article. For the authoritative technical material, use the canonical Ecosystem Positioning README and the versioned sources it indexes. This annex makes the collaboration pathways and contribution roles inspectable and traceable. Publication on Tegrity.AI does not imply peer review, independent validation, production readiness, adoption as a standard or endorsement by the ITU, FG-TIDA or any cited organisation.
Annex 10 Collaboration Guide
Specific tasks to expand and test the corpus
Question answered. What work can an outside person do to strengthen or refute the claims?
Coverage.Open-ended tasks by discipline, with inputs, expected outcomes, and limits of authority. The tasks do not presuppose institutional acceptance or favorable results.
Reading rule. This guide turns the corpus validation needs into open-ended tasks. Each contribution must document inputs, method, negative and positive results, authority limits, and relationship to supporting appendices.
Generalist and cross-functional contribution routes
Technical validation remains essential, but this programme cannot be advanced by technical specialists alone. A rigorous research corpus also depends on people who can organise work, make evidence findable, improve the reader experience, coordinate institutions and carry a technically bounded result into the places where it can be examined and challenged.
The following contribution routes are therefore explicitly in scope:
- Coordination and programme management: defining work packages, dependencies, review gates, schedules, decision records and handovers so that evidence is not lost between contributors.
- Repository and publication operations: preparing material for IMSV or Tegrity.AI repositories, maintaining versioned and commit-pinned references, or helping publish suitable outputs in external repositories and research channels.
- Communication and dissemination: translating technical work into accurate briefings, articles, presentations, events, professional dialogue and other formats without inflating the underlying claim.
- Editorial and visual design: improving information architecture, diagrams, tables, document navigation, accessibility and visual explanation while preserving the technical meaning.
- Proofreading and editorial review: checking language, internal consistency, references, terminology, citations and reader continuity in English, Spanish or other relevant languages.
- Institutional coordination: connecting the work with standards bodies, professional communities, companies, public institutions, universities and other legitimate review environments while keeping authority and endorsement boundaries explicit.
- Operational and reader-perspective testing: examining whether a case, interface, control or explanation remains usable by practitioners and understandable by an informed non-specialist.
- Other scoped support: translation, documentation, research operations, infrastructure, convening, data preparation and comparable contributions that have a clear brief, owner, deliverable and review route.
How these contributions are accepted
A contribution is accepted because it satisfies a defined brief and produces an inspectable deliverable—not because the contributor is assumed to possess authority outside that scope. Every contribution should identify its source material, changes made, reviewer, version or commit where applicable, and any unresolved limitation.
Authority boundary
Generalist and cross-functional work can materially strengthen clarity, traceability, coordination, usability and reach. It does not by itself validate a formal, empirical or technical claim; alter the canonical corpus; confer product certification; or imply endorsement by the ITU, FG-TIDA or any cited institution. Where specialist review is required, the contribution must be handed to the relevant technical or institutional owner.
Participation route. Individuals, practitioners, companies and institutions can offer cases, architectures, operational challenges, standards questions, professional time, infrastructure or other support through the Tegrity.AI Industry Reference Group. Participation and support do not confer technical influence, product certification or standards endorsement; technical conclusions remain independent.
Synthesis and use
The guide transforms open-ended questions into reproducible assignments routed through ten flexible, non-exclusive AIRG contribution tracks (A–J). A complete collaboration identifies versions, methodology, configuration, success criteria, positive and negative outcomes, human workload, authority limits, and replication archives. It should be able to reinforce, correct, or refute without presupposing institutional adoption.
Document navigation
- Article and source: When the Controls Work but the System Fails · Annex 0 — Complete Source and Concordance
- Supporting material: Annex 9 — Claims and Evidence Appendix · Annex 11 — Complete Map of Sources and Links
- Reproducible technical corpus: structural-awareness-contributions — commit 8f17843c568114f31cc0ad486b4a1303396021e6
How to use this guide
This appendix converts the open questions in the corpus into tasks that an external person or team can perform, critique, or refute with reproducible results.
Each collaboration must define version, scope, method, resources, oracle, threshold, human burden, authority, and replay archives. Negative results are as valuable as positive ones, and institutional adoption is never assumed.
Recommended route
Choose one or more AIRG contribution tracks; confirm inputs and acceptance criteria; run and retain traces; deliver results, limits and reproduction before proposing a conclusion.
Table 1. Canonical AIRG contribution tracks
Track | Contribution area | Typical contribution | Typical output |
|---|---|---|---|
A | Independent Research, Evaluation & Challenge | Evaluate whether a claim, method or proposed control is actually supported by evidence. Independently reproduce or challenge results; design tests, metrics and benchmarks; compare strong baselines; perform adversarial or formal review; assess evidence quality and limits. This track primarily evaluates evidence and claims rather than implementing production systems. | Replication note, benchmark/test protocol, adversarial review, formal model, comparative evaluation, evidence annex or methodological recommendation. |
B | Engineering, Implementation & Deployment Validation | Build, integrate, instrument, deploy or technically modify systems and controls, then validate how they behave in realistic environments. Implement architectures, interfaces and tooling; run pilots; test interoperability and deployment behaviour. This track primarily produces and validates working technical implementations rather than independently assessing research claims. | Code, fixture, reference implementation, deployment/test report, interoperability result, technical architecture, implementation finding or validated engineering requirement. |
C | Enterprise Governance, Information & Stakeholder Readiness | Provide or review governance cases; develop and test frameworks for decision rights, accountability, information readiness, data ownership and stakeholder governance; map enterprise constraints, control gaps and organisational dependencies. | Governance case, governance framework or matrix, RACI/decision-rights map, information-readiness assessment, stakeholder map, control model, policy/requirement proposal or enterprise operating-model analysis. |
D | Strategy, Business Value & Competitive Advantage | Assess where AI creates genuine process, organisational or market advantage; analyse economics and trade-offs; contribute strategy cases and frameworks; test adoption priorities, capability differentiation and second- or third-order business effects. | Strategic case, value model, ROI/TCO analysis, capability map, market/competitive analysis, investment criteria, adoption framework or business decision brief. |
E | Operational & Implementation Field Evidence | Provide real implementation and production evidence: operational constraints, incidents, failure modes, workarounds, dependencies, drift, escalation problems, production signals and practitioner observations that show what actually happened in the field. | Anonymised implementation case, incident/failure record, operational evidence annex, workflow/dependency map, production observation, lessons-learned record or negative reference case. |
F | Human, Social & Interdisciplinary Perspectives | Analyse human judgement, oversight, authority, trust, comprehension, behaviour, incentives, responsibility and social or organisational effects; contribute interdisciplinary frameworks, critiques and cases. | Conceptual analysis, human-factors protocol, behavioural or ethical review, legal/policy issue note, interdisciplinary case analysis, evaluation criteria or framework proposal. |
G | Standards, Institutional & Programme Coordination | Map relevant standards and institutional routes; prepare or review contribution packages; coordinate external exchanges, working groups, workshops and review cycles; structure work packages, dependencies and follow-up. | Standards mapping, contribution/submission package, liaison or institutional brief, work plan, workshop/review record, minutes/action register or documented institutional pathway. |
H | Knowledge, Publication & Communication | Turn validated work into clear, traceable and reusable knowledge assets; improve documentation and repository structure; edit or translate material; create visual explanations; support publication, teaching and dissemination without inflating claims. | Release-ready document, repository package, article, presentation, diagram, glossary, translation, teaching material, publication asset or event/session content. |
I | Resources, Infrastructure & Support | Provide compute, testbeds, tools, licences, datasets, professional services, venues, logistics, field support, in-kind resources or financial support for agreed AIRG work. | Defined infrastructure or resource package, dataset/tool access, specialist service contribution, event/logistics support, scoped sponsorship or patronage record. Resource or financial support does not determine technical conclusions. |
J | Open & Emerging Contributions | Propose a clearly scoped new contribution, cross-domain connection, emerging discipline, experimental line of work or candidate new track that does not fit the existing structure. Ideas are not confined to this track; they are welcome across all tracks. | Short scoped proposal explaining the problem, relevance, expertise offered, intended contribution, expected evidence or deliverable and proposed next step. |
Table 2. Minimum package to accept a result
field of the package | Minimum required | Rejection if missing |
|---|---|---|
Version and scope | Commit, artifacts, domain, and exclusions. | It is impossible to know what was tested. |
Method and configuration | Procedure, parameters, prompts, and dependencies. | The execution is not reproducible. |
Inputs and resources | Data, tools, budget, and time. | The comparison is no longer matched. |
Controls | Baseline, ablation and treatment defined. | The result cannot be attributed to the mechanism. |
Oracle and Threshold | Metric, success condition, and tie-breaking rule. | The result allows for retrospective interpretation. |
Human load | Time, information, and actions of the supervisor. | The true cost of governance is hidden. |
Authority | Principal, mandate, approvals, and prohibited actions. | A technically valid output may be illegitimate. |
Traces and results | Logs, hashes, incidents, residual, and conclusion. | There is no auditable chain between test and claim. |
Reading conclusions
Conclusion 1. A useful collaboration can reinforce, correct, or refute; it has no predetermined outcome.
Conclusion 2. Independence requires separating shared infrastructure from logic subject to comparison.
Conclusion 3. FG-TIDA is a pathway for consideration and review, not a statement of adoption.
Preservation and navigation
Disciplinary tasks, references to FG-TIDA and the readiness map, and authority boundaries remain complete in the program and source links.
Technical collaboration examples
The examples below show how technical work may be routed through the canonical AIRG tracks; they are not a separate contribution taxonomy.
Systems and Agent Engineering
- Reproduce a route B0 to B3 with independent implementations and paired resources.
- Publish configurations, versions, frozen facts, oracle, thresholds, human review loads, and the disposition at each gate.
- Separate shared controls from truly independent logic and log integration or timing failures.
Formal methods and computability
- Audit the projected clauses of A23 and the counterexamples of P3, P5 and P6.
- Attempting to build models that meet the stated requirements but violate the corresponding principle.
- Distinguish relative closure, Boolean independence, finite sufficiency, and universal guarantees.
Adversarial red teaming
- Look for correlated repetition presented as corroboration, silent amplification of authority, replay, expiration, races, and obsolete actions.
- Pre-register the attack, the success criteria, and the stopping conditions before observing the outcome.
- Preserve falsifications and corrections in the record, even when they weaken the hypothesis.
Domain specialists
- Company and human supervision: evaluate workload, usefulness and actual completion of the work.
- Urban mobility: setting legitimate restrictions, shared resources, emergency and operational deadlines.
- Customer remediation and payments: separating finding, individual mandate, campaign, and aggregated authority.
- Software and databases: testing semantic TOCTOU, queues, revalidation and rollback.
- Rights and provenance: verifying identity, license, transformation, attribution and dispute resolution.
Psychology and human-agent interaction
- Measure when the required supervision exceeds the available capacity.
- Evaluate how residual uncertainty is communicated without inducing automaticity or fatigue.
- Design interventions that preserve human agency, the possibility of challenge, and repair.
Standardization and FG-TIDA
- Map functional responsibilities, handoff semantics, and conformance material to the group’s published mandate.
- Present the proposal as material for consideration and review, not as an adopted standard.
- Document participation, comments, and decisions through the applicable official channels.
Source inputs
A comparative follow-up must trace each conventional control to documented capabilities and configuration, and distinguish those from additional symbolic repairs. Candidates may share the requirements, observations and neutral test infrastructure, while independently implementing the mechanism whose benefit is being assessed. Each result should be scored against the oracle without requiring the candidates to agree, with failures retained and decision burden recorded. This preserves a fair opportunity for conventional engineering to succeed and gives the regime-change hypothesis a test that can distinguish outcomes.
Within trust and interoperable identity, this direction aligns with FG-TIDA‘s remit — architectural approaches, trust-lifecycle frameworks, machine-readable trust information, use cases and assessment criteria — and the EA specification-preparation map organizes the proposed contribution into functional responsibilities, handoff semantics and conformance material for review through the group’s own process. That is a route for consideration, not a claim of adoption.
None of this makes Ecosystem Awareness the only way to satisfy the fourteen requirements, and it is not offered as one. It is a candidate reference vocabulary, informed and challenged by the process of failure-mode construction and ablation described in Part I, for a problem — maintaining a decision’s justification as the regime around it shifts — that has to be solved somehow. A reader who satisfies the same requirements through an entirely different architecture, using different names or component boundaries while preserving the required distinctions, is exactly the outcome this reference hopes for.
Generalists, coordination and institutional support
Technical specialisation is not required to contribute. Generalists can connect disciplines, translate between technical and institutional audiences, frame real-world cases, review clarity, coordinate programmes, support publication in our repositories or suitable external repositories, design and proofread materials, communicate and disseminate the work, and organise institutional participation. Other forms of support that make the work rigorous, usable and accessible are equally welcome.
Individuals and organisations that want to support testing, independent review and coordination can participate through the Tegrity.AI Industry Reference Group.