Appendix A: Research Methodology and Source Attribution¶

This appendix documents how the TRIRIGA-to-MREF Migration Guide was built, what sources informed it, and how to evaluate the confidence of individual claims. It exists so that reviewers can assess the guide's credibility on its own terms rather than relying on trust.

How the Guide Was Built¶

This guide was authored using AI-assisted research and drafting with human review at every phase. The process worked as follows:

Phase-by-phase research — Each of the six chapters was researched independently against a curated set of IBM documentation, internal enablement materials, and public technical references before any drafting began.
Dual-source verification — Every technical claim was checked against at least two independent sources: a curated document corpus (via Google NotebookLM) and a separate web search for corroboration or contradiction. No claim relied on a single source alone.
Human review per phase — After each chapter was drafted, a senior TRIRIGA consultant reviewed the content for accuracy, relevance, and appropriate scope before proceeding to the next phase.
Retroactive source attribution — After all six chapters were complete, a systematic remediation pass tagged every technical claim with a confidence level and mapped it to its supporting source(s). This appendix and the accompanying verification log document that process.

The AI tooling accelerated research and drafting. The methodology, source selection, scope decisions, and final editorial judgment were human-directed throughout.

Source Corpus¶

Research was conducted against seven curated document collections hosted in Google NotebookLM, each focused on a specific domain:

#	Collection	Contents	Primary Use
1	TRIRIGA to MREF Migration Guide	IBM migration guides, MREF deployment docs, MAS 9.x architecture references, partner enablement decks	Primary source for all MREF migration claims, OM tool behavior, infrastructure requirements
2	IBM TRIRIGA Release Notes 11.0–11.6	Official release notes for every TRIRIGA Application release from 11.0 through 11.6	Version-specific prerequisites, breaking changes, upgrade sequencing
3	TRIRIGA Training Documentation	IBM TRIRIGA platform fundamentals — business objects, workflows, forms, reporting	Background context for explaining what carries over vs. what changes
4	TRIRIGA UX App Building	UX application framework documentation, component patterns	UX migration considerations in Chapter 3
5	TRIRIGA/ESRI Integration	Esri GIS integration technical documentation	GIS integration carryover assessment
6	OSLC/TRIRIGA	OSLC API specifications and TRIRIGA integration patterns	Integration protocol migration in Chapter 5
7	TRIRIGA Integration Object	Integration object definitions, inbound/outbound patterns	Integration adaptation in Chapter 5

These collections contain a mix of publicly available IBM documentation, IBM Support articles, IBM Redbooks content, and internal IBM partner enablement materials. The internal materials (noted in individual citations as "IBM internal PDF" or similar) are not publicly accessible but are available to IBM consulting teams through standard partner channels.

The Dual-Source Research Rule¶

Every factual claim in this guide was researched using a mandatory dual-source process:

NotebookLM query — The relevant document collection was queried first. NotebookLM returns answers grounded in the uploaded source documents with inline citations to specific pages and passages.
Independent web search — A separate web search was conducted for the same claim to find corroborating (or contradicting) evidence from IBM Docs, IBM Support, IBM Community forums, or third-party technical blogs.
Reconciliation — Where sources agreed, the claim was tagged Verified. Where the web search found no corroboration but the NotebookLM source was credible, the claim was tagged Likely. Where neither source provided confirmation, the claim was tagged Needs Validation.

This rule was enforced without exception across all six chapters during the remediation pass. Claims that predated the dual-source rule (from early drafts) were retroactively re-verified.

Confidence Tag Rubric¶

Every technical claim in the guide carries one of three inline confidence tags. The rubric below defines when a tag is applied and what it means.

Tag Definitions¶

Tag	Meaning	Criterion
`<span class="confidence-tag verified">Verified</span>`	Directly supported by source documentation	A specific NotebookLM source document, IBM Docs URL, or IBM Support article states this claim directly
`<span class="confidence-tag likely">Likely</span>`	Reasoned inference from adjacent sources	The claim follows logically from adjacent sourced material, but no single document states it verbatim. Adjacent sources are cited.
`<span class="confidence-tag needs-validation">Needs Validation</span>`	Unconfirmed — field verification required	No source confirms the claim. It is a reasoned assertion based on architectural logic or limited partner reports. The consulting team should verify in their target environment.

What Requires a Tag¶

A claim requires a confidence tag and source footnote if ANY of the following are true:

Version, SKU, or product identifier — specific version numbers, AppPoints values, product edition names
Behavioral contradiction — any MREF/MAS behavior that contradicts default TRIRIGA expectations
Procedural gate or hard constraint — steps where skipping or reordering causes failure
DB-migration carryover claim — what does or does not survive the database migration
Numeric threshold or limit — batch sizes, timeouts, pool sizes, heap ratios, performance baselines
Third-party tool behavior — claims about OpenShift, Db2, Kafka, MongoDB, or other infrastructure components
Architectural distinction — any claim that distinguishes TRIRIGA, TAS, and MREF as separate platforms

What Does NOT Require a Tag¶

The following are excluded from tagging:

Framing sentences that paraphrase a claim already tagged on the same page
Checklist questions and interview prompts (consultant scaffolding, not factual claims)
Table headers and column labels
"Key Takeaway" callout boxes that summarize already-tagged content
Generic consulting procedures ("schedule a kick-off call with stakeholders")

Honest Disclosure: MREF Documentation Limitations¶

MREF (Maximo Real Estate and Facilities) is an early-release product as of the research completion date. This creates specific limitations that readers should be aware of:

Limited public documentation — IBM's public documentation for MREF is still maturing. Some claims in this guide rely on IBM internal partner enablement decks, Qvidian content packages, and pre-release architecture documents that are not publicly accessible. These are noted in individual footnotes.
Behavioral claims may evolve — MREF behavior documented here reflects the state of the product at research time. IBM may change default configurations, deployment procedures, or administrative workflows in subsequent releases.
Needs Validation tags are honest flags — Where we could not confirm a claim from any written source, we said so. These tags are not failures; they are the guide telling you where to verify against your specific environment and MREF version.

The guide's credibility rests on this transparency. Every claim is tagged, every tag has a defined meaning, and every source is traceable through the footnote system.

Research Completion Date¶

The research and source-attribution remediation for this guide was completed in April 2026. IBM documentation, product behavior, and deployment procedures referenced throughout reflect the state of MREF and MAS 9.x as of that date.

Readers working with later MREF releases should cross-reference claims tagged Likely or Needs Validation against current IBM documentation, as these are the most likely to have been superseded by updated official guidance.

How to Read Footnotes¶

Throughout the guide, technical claims are followed by superscript footnote markers (e.g., [^ch01-42]). Each footnote provides:

The source document or URL that supports the claim
The chapter and line reference where the claim appears

Footnotes are collected at the bottom of each chapter. A consolidated bibliography of all unique sources cited across the guide appears in the References section at the end of the combined document.

Source Mapping File¶

The complete machine-readable mapping of every tagged claim to its source(s) is maintained in scripts/source-mappings.json. This file contains:

The chapter, line number, and claim text for every tagged assertion
The source document(s) or URL(s) supporting each claim
Batch identifiers indicating when each mapping was created (original pass vs. remediation pass)

Verification Log¶

A spot-check verification log is maintained at .planning/citation-verification.md. This log records the results of independently re-verifying a sample of 10 claims per chapter (60 total) against their cited sources. The sample is weighted toward:

Claims sourced only to internal IBM PDFs (hardest to verify publicly)
Claims from high-density technical sections
Claims tagged Needs Validation or where no public citation was located

This log serves as the audit trail for reviewers who wish to challenge any individual claim in the guide.