Research Method & AI Use
How practitioner experience, prior work, implementation evidence, generative AI and adversarial review are used in this working paper.
This paper begins with practitioner observation and uses research and AI to test, sharpen and sometimes overturn it.
Where the thesis comes from
The starting point is experience with enterprise architecture, technology delivery and the gap between how organizations describe work and how work actually gets completed. The recurring observations are practical ones: process models that omit the judgment required to run them, systems that each hold only part of the business context, decision rights that live outside software, and automation that becomes brittle when exceptions become the work rather than an edge case.
Vyuham is an attempt to make those observations executable. Building agentic business units, authority boundaries and an execution harness turns an intuition into something that can fail in concrete ways. That implementation work is part of the research method, not a product demonstration attached to the paper.
This is therefore not presented as a conventional empirical study or as a systematic literature review. It is an experience-derived architectural argument. Claims about organizational behavior are treated as propositions to be tested against prior research and implementation evidence rather than as quantitative findings from a controlled study.
How prior work is used
Literature is used for three purposes. First, to determine whether an observation already has an established name or body of work. Second, to identify prior art that narrows or defeats a proposed contribution. Third, to find stronger conceptual tools than the paper initially used.
The intended standard is that substantive claims attributed to prior work are checked against the original or primary publication before they are retained in the published sections. A citation is not evidence merely because a model produced it. Where a source cannot support the proposition being made, the proposition should be narrowed, moved, or removed.
Use of generative AI
Generative AI tools are used extensively in the development of this working paper. They assist with literature discovery, source retrieval, comparison of adjacent frameworks, synthesis, drafting, editorial revision and adversarial review. They are also used to expose the argument to competing interpretations and to identify claims that require stronger evidence.
The role of AI is deliberately broad, but authorship is not delegated. The thesis, examples drawn from experience, architectural judgments, selection of claims, interpretation of evidence, disposition of criticism and final editorial decisions remain the author's. AI output is treated as research assistance and draft material, not as an authority in itself.
Adversarial review
Completed sections are subjected to a red-team pass that looks for prior art, unsupported novelty claims, conceptual conflation, missing adversaries, citation problems and arguments that would fail in front of practitioners from architecture, security, legal, finance or operations.
The red-team output is retained even when a finding is rejected or withdrawn. A living audit log records which findings were mitigated in the manuscript, which were deferred to a later section, which remain open, and which attacks were themselves found to be unsound. This is intended to prevent the paper from silently forgetting inconvenient criticism as it evolves.
What counts as evidence
The paper uses several kinds of evidence and does not treat them as interchangeable. Published research establishes prior concepts and known findings. Standards and industry frameworks establish contemporary practice and terminology. Vyuham experiments provide implementation evidence about whether the proposed architecture can actually operate. Practitioner experience supplies the initial observations and the test cases that motivated the inquiry.
Experience can reveal a problem worth studying, but it does not by itself establish a general law. An experiment can demonstrate that an architecture works in one bounded setting, but it does not prove that it scales to an enterprise. Industry adoption can show relevance without establishing correctness. The argument should state which kind of evidence it is relying on rather than flattening them into the same category.
Author accountability
The author is responsible for the claims that remain in the paper. If a source is mischaracterized, a distinction fails under scrutiny, or an experiment contradicts the thesis, responsibility does not transfer to the AI system that assisted in producing the draft. The working-paper format is meant to make revision possible, not to dilute that accountability.
The objective is not to prove that the original intuition was right. It is to see what remains after experience, prior work, implementation and adversarial criticism have all had a chance to change it.