TL;DR: AI isn’t getting smarter in the way most people think. The real shift is workflow. If you’re still using AI like a chatbot, you’re three years behind.
Every conversation starts from zero because the model has no persistent memory of you, your work, or your context. Claude Skills solve this by letting you build a reusable knowledge library, one markdown file per task, that the AI can pull from on demand.

Read full post here

TL;DR: AI isn’t getting smarter in the way most people think. The real shift is workflow. If you’re still using AI like a chatbot, you’re three years behind.
Every conversation starts from zero because the model has no persistent memory of you, your work, or your context. Claude Skills solve this by letting you build a reusable knowledge library, one markdown file per task, that the AI can pull from on demand.

Don’t want to read the blog, watch the video instead!

Click here to listen to podcast

I was busy the last few weeks getting ready for a conference and couldn’t dedicate my normal time to keeping up with AI. It had been a good four weeks since I’d been able to really go deep, and in just those four weeks the bleeding edge of workflows had changed.

If you’re in the early stages of learning AI, the capabilities feel relatively stable. You’re probably using chatbots, and if you’re adventurous, you’ve made a custom project or maybe a custom GPT. That’s a great start. It was also possible three years ago.

When you operate on the bleeding edge, there are major changes with almost every release. I’m not talking about AI intelligence or token limits. I’m talking about workflow. Think command line interfaces (CLI), more specifically Claude Code, and AI built directly into VS Code.

If you’re still using AI like a chatbot, congrats, you’re ahead of most people who aren’t using AI at all. But you’re about three years behind what’s now possible.

You need to start thinking of AI as a coworker you can offload real tasks to. I’ll write a separate post on Claude Code integration, but for now here’s the best way to explain where things are heading.

Context windows: the working memory problem

AI has what’s called a context window. Think of this as working memory (not really, but it’ll do for now). Every time you upload a file, ask a question, or get a response, it all has to be held in “memory.” Every time you talk to AI, it isn’t actually remembering your prior chats. What it’s doing is resending everything back and forth

I made this video a while back that explains this better:

Even with one million token context windows, if you upload a few large PDFs, a video or two, and some data, you’ll burn through that in thirty minutes of chat.

If you’ve seen the TV series Severance, AI is essentially a severed worker. The intelligence is fully intact in both contexts. The innie version is just as smart as the outie. But the innie has no access to anything the outie knows. Every task they need to perform on the severed floor has to be taught to them.

Every AI conversation starts the same way. The model walks onto the severed floor having never met you. Anything you’ve worked on together before, any preferences, any context about your job, has to be reintroduced unless you give it a way to access that knowledge on its own.

While not strictly true any more with custom instructions and a kind of persisting memory which auto updates, for this post lets assume that is not he case as it is very basic at best.

That’s the problem skills solve.

Build a Knowledge Library

New mindset: Google “Claude Skills” for the in-depth understanding.

Claude is the best AI at this right now, but the concept is coming to all AI eventually.

Take your last five years worth of projects, both in and out of work. Now imagine you had to train someone else to fully understand and perform these tasks. All they had to go from was your written instructions, knowledge, computer code, notes, and references. Everything would need to be in a machine accessible format.

That’s a lot of knowledge to upload every time you talk to AI.

The Library of You

This is the best metaphor I’ve used for explaining skills.

Imagine a library.

Each book is a part of your life at the task level.

Each book has an executive summary.

Each page contains what’s needed to complete the task: background knowledge, computer code, API information, instructions on how to learn more from other books in your library, lessons learned, things to watch out for, reference material, and so on.

Take the last project or task you completed at work or at home. If you had to document it step by step, including all the information listed above, it gets pretty big. Even for basic tasks, you have to provide all the relevant context.

A Concrete Example

Say you want to give a presentation at a conference on “Repurposing Sponsored Research Data for Collaboration Network Analytics.” Let’s just focus on the opening slides. You’ll probably need an introduction covering who you are, what you do, and why you’re qualified to speak on this topic.

Slide: Who am I?

• What you’re speaking about

• What you’ve done on this topic

• Relevant professional history

• Educational background

• What project from your job makes you qualified to speak on this

• What tools you use, what other projects are related

• Past talks and webinars

Sure, you could type this out every time you build a new presentation. But things get out of sync, and that’s a lot of duplication of effort. What if you want to write a blog post on it, change the audience, or repurpose the talk for an adjacent area?

Use Your Library

Let’s pull three books off the shelf: “Resume,” “Project Details,” and “Past Presentations.”

Behind the scenes, when you ask “make me an introduction for that talk,” the AI will:

1. Read the slide deck to understand the context

2. Read any guidance around the audience (level, familiarity with the topic, etc.)

3. Read your past presentations

4. Use all of this to draft an appropriate introduction

Even this simple act of generating an introduction isn’t actually simple. Humans take knowledge for granted. We can recall all of this stuff without much thought. But if you have to upload or type it out every time (which is essentially what you’re doing if you’re still thinking in terms of chatbots, projects, or custom GPTs), it adds up fast.

Now imagine you have to repurpose your slides for a different audience or level. Maybe a year from now you’ve improved the tools you use for this project. Or maybe you want to write a blog post, a how-to for your colleagues, or a nice infographic.

That’s more manual effort you have to expend every single time, unless you build the library once and reuse it.

The Shift in Mindset

The move from chatbot to coworker isn’t about a smarter model.

It’s about giving the model access to you: your work, your context, your accumulated judgment.

The intelligence has been there for a while. What’s new is the infrastructure to make your knowledge portable.

This isn’t free. You actually have to write the books. The first few skills feel like overhead. The payoff shows up the third or fourth time you reach for one and realize you didn’t have to re-explain anything.

If you take one thing from this post, it’s that the bottleneck is no longer the AI.

It’s how much of yourself you’ve made machine-readable.

More context AI Feels Useless Because It Can’t See Your Work (Short Version)
More context Building a Task System with Structured Markdown Files

How to start

Don’t try to retroactively document the last five years of your work. That’s a recipe for never starting.

Start now, with the next project or action item on your plate. Open a blank markdown file. Write the how-to as you do the work. Then do the same thing for the next task. And the next. Twelve weeks in, you’ll be surprised how large your knowledge base has gotten.

The foundation unit is the .md file. As I covered in a prior post, I’m actively moving toward a “Files Over Apps” framework, where the foundation of all your work is a raw text file rather than something locked inside a proprietary tool. Plain markdown is the lowest friction format for AI to read and write. No export step, no API, no vendor lock-in. The file is the file.

This is also why Obsidian matters.

https://obsidian.md/

Obsidian sits on top of a folder of plain markdown files and turns them into a navigable, linked knowledge base. Backlinks, graph views, plugins, presentation modes, all working on the same raw files. The files stay portable, in a format any tool (including AI) can read. But on top of that raw layer, Obsidian gives you an interface humans actually want to use. That dual nature is why I think Obsidian becomes the foundation tool for most knowledge workers in the next few years. The files work for AI. The interface works for you.

Obsidian is powerful enough that it needs its own multi-part series, which I’ll get to in a later post.

For now, just know that the .md files you start writing today will plug into it without any conversion work later.
Obsidian is free, and has a very steep learning curve so start now
https://obsidian.md/

My additional notes using Obsidian
Markdown + Kanban - by Robert Pilgrim

Today, start a running Word file (convert it to text/md later) and see what you end up with in a few weeks! details project, task, relevant discussion points etc. 4 weeks from now just give it to AI and you will be surprised how powerful that file is!

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: The 2026 Research Analytics Summit packed a dense program into three days. Rather than send one long recap, I have grouped the sessions I tracked into six themes, each with its own deep-dive post. This is the index. Click through to the themes that match your work.

A note on how this was written. This series was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat the series as a curated overview of the program, not a firsthand recap.

Why a Series

The Summit ran from April 19 to 21, 2026, in Rhode Island. I attended in person, presented WM1 (Sponsored Research Collaboration Network Analytics), and sat on the G2 Operationalizing Data Governance panel. With a dense program running across multiple concurrent tracks, no attendee saw more than a fraction of what was on offer. A single recap would either be exhausting to read or shallow to write.

So I split the analysis into six themes. Each post stands on its own. Read the ones that match your job, skip the rest, or work through the whole set if you want the full picture of where the field is.

The Six Themes

The themes group naturally into three pairs: the foundations layer, the outputs layer, and the frontier.

1. AI-Enabled Research Administration — When AI Stops Reporting and Starts Diagnosing

2. Competitive Funding Intelligence — Reading the Funding Map Before the Money Moves

3. ETL and Data Cleaning Mastery — The Unsexy Layer That Decides Everything

4. Institutional Data Governance — Governance Stops Being a Slide

5. Narrative-Driven Dashboards — When the Dashboard Stops Being a Deliverable

6. Responsible Evaluation (SCOPE Framework) — What We Measure, and Whether We Should

Video Overview of the Main Themes and Takeaways

Foundations: The Unsexy Layer That Everything Sits On

Outputs: What Leadership Actually Sees

The Frontier: Where the Field Is Going

Where to Start

If you only have time for one post, pick the one that matches the work on your desk this month. If you want a single recommendation, start with the AI-Enabled Research Administration post. It captures the most pronounced shift on the program and links to the sessions most likely to influence the next eighteen months of investment decisions.

If you came home from the Summit with a stack of business cards and no time to follow up, the Speakers and Institutions lists in each post are the fastest way to reconstruct who works on what.

A Closing Note

This was the first Summit I have come back from genuinely uncertain how to summarize. The field is moving on too many fronts at once. The series is my attempt to make sense of all of it without flattening any of it. I hope it saves you some time.

If you missed the Summit and want the full program, the official agenda is available at analyticssummit.uky.edu. The 2027 Summit dates have not yet been announced.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.TLDR: Research evaluation is having a values reckoning. The sessions in this thread converged on a single message: metrics without methodology are a liability, and the SCOPE Framework from INORMS is the most credible response the field has produced.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For two decades, research evaluation has been a numbers game. Citations, h-indices, impact factors, dollars in, papers out. The 2026 Research Analytics Summit made it clear the field is no longer comfortable with that posture. Sessions in this thread treated evaluation as a values question first and a measurement question second.

The center of gravity was the SCOPE Framework: a five-stage model from INORMS (the International Network of Research Management Societies) that asks evaluators to Start with what you value, assess Context, explore Options for evaluating, Probe deeply into methods and impacts, and Evaluate the evaluation itself. SCOPE is not a metric. It is a discipline.

Sessions Covered

Grouped by theme:

The SCOPE Framework

Sessions in this group introduced and applied SCOPE directly. The pre-conference workshop combined conceptual grounding with hands-on exercises. The follow-up conference session traced how metric-driven evaluation distorts institutional values and demonstrated SCOPE applied to three theoretical use cases.

• WA1: WORKSHOP: Responsible Research Evaluation Using the SCOPE Framework

• C3: From Metrics to Framework: Advancing Responsible Research Evaluation

Beyond Citation Counts

Sessions in this group tackled the practical problem: how do you build evaluation systems that recognize policy impact, early-career contributions, and forms of scholarship that citation counts ignore?

• D5: From Data to Decisions: Building Responsible Policy Impact Metrics via Policy Citation Data

• E4: Evaluation of Research Impact for Early Career Research Professionals

Ethical Foundations

One session asked the hardest question in the room: what gives our measurements and judgments their authority in the first place?

• G5: Ethical and Epistemic Foundations of Research Analytics and Evaluation

Speakers and Institutions

Speakers from several organizations contributed to this thread.

U.S. Institutions

• Unity Health Toronto: Erica Conte

• Indiana University Bloomington: Wen Qi

• Virginia Tech: Rachel Miles

• Oregon State University: Puja Agarwal

• University of Kentucky: Dr. Andrea Christelle

International

• Loughborough University (UK): Dr. Elizabeth (Lizzie) Gadd

Industry

• Overton: Euan Adie

1. The SCOPE Framework: Values Before Metrics

SCOPE inverts the usual order of operations. Most evaluation projects start with available data and back into the question. SCOPE forces the question first.

WA1: Responsible Research Evaluation Using the SCOPE Framework

Erica Conte (Unity Health Toronto), Dr. Elizabeth (Lizzie) Gadd (Loughborough University)

Conte and Gadd ran the workshop that set the conceptual frame for the rest of the conference. SCOPE foregrounds three things most evaluation processes skip: values (what does the institution actually care about?), context specificity (what works for one discipline or career stage may distort another), and methodological rigor (does the chosen method answer the chosen question?). The workshop combined conceptual grounding with practical exercises, so participants left with a working tool, not a slide deck.

What makes SCOPE useful is that it is portable across disciplines and institutions. It does not prescribe metrics. It prescribes a process for choosing them.

C3: From Metrics to Framework

Wen Qi (Indiana University Bloomington), Rachel Miles (Virginia Tech)

Qi and Miles structured their session in two parts. Part one traced how evaluation systems develop in the wild, and how well-intentioned metrics distort the institutional values they were meant to serve. Hard-to-quantify scholarship gets marginalized. Disciplines with longer impact horizons look weaker than they are. The cultural and structural implications compound year over year.

Part two introduced SCOPE as the corrective and demonstrated it through three theoretical use cases examined during an Institute of Museum and Library Services (IMLS)-funded conference on SCOPE implementation. Three forthcoming manuscripts focus on arts and humanities, institutional excellence, and promotion and tenure. That is a meaningful publication pipeline behind a framework that was, until recently, a conceptual proposition.

The takeaway: SCOPE is no longer aspirational. Working groups are applying it, documenting it, and producing peer-reviewed guidance.

2. Beyond Citation Counts: Building Better Signals

Citation-based evaluation rewards a narrow slice of what research actually produces. Sessions in this group showed what better signals look like in practice.

D5: Responsible Policy Impact Metrics via Policy Citation Data

Euan Adie (Overton)

Societal impact has been on every research office’s roadmap for a decade. Adie’s session got specific about one of the most measurable forms of it: policy impact. He moved from foundational concepts to practical implementation, covering what policy impact data actually is, why it matters, and how to build measurement systems that improve institutional decision-making.

The technical substrate was Overton’s policy citation data, which surfaces references to scholarship inside federal agency reports, congressional documents, state guidelines, and think tank publications. The methodological substance was harder: defining KPIs that align with institutional goals, ensuring data quality, avoiding traps that make policy metrics misleading or useless. Adie covered semi-automated implementation and live monitoring of policy engagement, with explicit attention to responsible metrics development.

This is the kind of impact data that has historically been collected by hand, retroactively, for REF-style exercises. Building it into a continuous measurement system changes what institutions can ask.

E4: Evaluating Research Impact for Early Career Research Professionals

Puja Agarwal (Oregon State University)

Agarwal addressed the population most damaged by traditional evaluation: early-career researchers. Citation counts are a lagging indicator. By the time the citations arrive, the tenure clock has already run. Publication volume rewards a narrow slice of contribution and quietly penalizes collaboration, engagement, interdisciplinarity, and societal impact, exactly the signals early-career researchers produce first.

Her response is a technical, data-driven evaluation framework built at the institutional level: cross-disciplinary, capacity-focused, designed to elevate early-stage impact signals rather than wait for citations that arrive a decade late. She presented it as a replicable model with practical tools, not a one-off institutional artifact. Where Qi and Miles diagnose the distortion, Agarwal builds an alternative.

3. Ethical Foundations: Whose Values, and Why?

The most philosophically demanding session of the conference closed the thread.

G5: Ethical and Epistemic Foundations of Research Analytics and Evaluation

Dr. Andrea Christelle (University of Kentucky)

Christelle asked the question that makes most analytics professionals uncomfortable: what gives a measurement its authority? Her argument: research analytics and evaluation rest on epistemic foundations with ethical implications, and we typically pretend otherwise.

The distinction she drew was sharp. Analytics asks “what is the case?” Evaluation asks “what is good?” Treating them as the same question is how institutions end up with metrics that measure something defensibly while saying nothing useful about whether the underlying activity should be encouraged.

Christelle pushed on a specific limitation in current responsible-evaluation discourse. Articulating what stakeholders do value (descriptive) is not the same as asking whether those values should guide evaluation (normative). SCOPE asks the first question well. The harder work is the second. Her session covered how to distinguish ethical reasoning from procedural compliance, how to recognize value assumptions baked into metrics, and how to evaluate practices using normative criteria like privacy, autonomy, and institutional responsibility.

Without this session, responsible evaluation becomes another compliance checklist.

Key Takeaways

Reading across the abstracts in this thread, four patterns stand out.

1. Values first, metrics second. SCOPE is the consensus answer. Every session in the thread either taught it, applied it, or argued for going further. Institutions still starting from “what data do we have?” are working backwards.

2. Context is not optional. Arts and humanities, early-career researchers, policy-engaged scholars, and interdisciplinary teams all get penalized by citation-default evaluation. Responsible frameworks treat context-specificity as a design requirement, not a nice-to-have.

3. Policy impact is becoming measurable. D5 makes the case that the Overton-style data layer changes what institutions can credibly claim about societal impact. Expect policy citation tracking to move from REF-cycle exercise to continuous KPI in the next two years.

4. Compliance is not ethics. G5 is the session that keeps this whole conversation honest. Asking what stakeholders value is descriptive. Asking whether those values should guide evaluation is normative. Responsible evaluation programs that skip the second question are doing governance theater.

If you missed the conference, the two sessions worth seeking out are WA1 (Conte and Gadd) for the operational framework and G5 (Christelle) for the philosophical floor under it. If you take home one framework, make it SCOPE, and read it as a process, not a checklist.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: Dashboards are no longer the finish line. The 2026 Research Analytics Summit made clear that the field has moved past “we built a Tableau dashboard” toward harder questions: who is the audience, what decision does the dashboard support, what definitions does it lock in, and what story does it tell. Sessions across the program showed how research offices are designing for action, not just display.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For a long time, the dashboard was the deliverable. A team got a request, built a Tableau or Power BI page, shipped it, and called the project done. The 2026 Summit retired that model. Across the program, the consistent message was that a dashboard without a clear audience, a locked KPI definition, and a narrative arc is not a finished product: it is a screen.

Three currents ran through the theme. The first is design discipline: building dashboards as decision tools, not as data buffets. The second is operational substance: live data refresh, federated source integration, role-aware access. The third is specialization: geospatial, compliance, faculty performance, and other use cases where generic templates fail.

Sessions Covered

Grouped by emphasis:

Foundations: Building Dashboards That Work

Workshops and conceptual sessions on how to design dashboards that actually drive action. Tool training, narrative design principles, KPI definition discipline, and shared data literacy across stakeholders.

• WA2: Tableau Dashboards Made Easy: a Beginner-Intermediate Workshop

• B3: From Strategy to Screens: Designing Dashboards That Support Decision-Making

• I2: From Data to Decisions: Designing Narrative-Driven Dashboards for Research Administration

• I4: It Depends!: Building Data Literacy as a Shared Language for Research Analytics

Operational Dashboards in Practice

Working systems built and deployed at specific institutions. Enterprise data warehouses, automated expenditure monitoring, faculty performance, award management, and the platform-selection question.

• A6: Enhancing Research Performance Reporting via an Enterprise Data Warehouse and a Self-Service Analytics Portal

• B5: Data-Driven Award Management: Turning Reporting and Analytics Into Action

• F4: Automating Expenditure Monitoring: Enhancing Decision-Making With Power BI Dashboards

• G4: Research Analytics Dashboards: Visualizing Faculty Performance Data for Actionable Insights

• C2: Bridging Data Silos in Academia: Smartsheet, Tableau, and Power BI as Catalysts for Transparent Research Analytics

Specialized Use Cases

Domain-specific dashboards where generic templates fall short: research security compliance, geospatial analysis, audience-tailored reporting, and three lightning-talk case studies.

• C1: Developing a Research Security Training Compliance Dashboard Through Cross-Team Collaboration

• D4: One Dataset, Many Audiences: Designing Research Reporting That Actually Gets Used

• H2: Research Administration Is Geospatial: A Practical Guide to Integrating Location-Based Data Into Data Dashboards and Analysis

• B6: Lightning Talks on Practical Analytics, an AI-Powered Connectome Tool, and Reviewer Matching

Speakers and Institutions

Speakers from many organizations contributed to this thread of the program.

R1 Research Universities

• Rutgers University: Julia Zappi, Christopher Perkins

• Emory University: Alex Wagner

• Arizona State University: Ferenc Feher, Audrey Reichard

• Stanford University: Anna Romanowska-Pawliczek

• Columbia University: Janki Patel

• University of Arizona: Sarah Dasher, Abraham Silva

• Texas Tech University: Taylor Fidler, Carrie Romo

• University of Texas at San Antonio: Hanin Alhaddad

• Michigan State University: Jack Lipton, Nathan Kuhn

• University of Kentucky: Elizabeth Larimore, Laura Lodder

• Penn State University: Paulina Krys

• Northeastern University: Laura Beaupre

• University of Nebraska: James Geiger

• Colorado State University: Lori Ann Schultz

Other U.S. Institutions

• Pepperdine University: Alex Howard

• Loyola Marymount University: Rachel Marr

• Norco College: Hayley Ashby

• OSU Center for Brain Injury Recovery and Discovery: Colin Edwards

International

• Edith Cowan University (Australia): Michelle Duryea

Industry

• Cayuse: Matthew Kingore

1. Foundations: Building Dashboards That Work

Sessions in this group tackled the conceptual work that determines whether a dashboard ever gets used. The pattern is consistent: tool fluency is necessary, but it is the smaller half of the job.

WA2: Tableau Dashboards Made Easy

Julia Zappi, Christopher Perkins (Rutgers University), Alex Wagner (Emory University), Ferenc Feher, Audrey Reichard (Arizona State University)

A hands-on Tableau workshop pitched at beginner-to-intermediate practitioners. The session used publicly available NIH RePORTER data to walk through cleaning, import, and the construction of interactive visualizations. The workshop revisited basic concepts from the 2025 Summit before moving into intermediate territory. The Rutgers and Emory data analytics teams (established in 2019 and 2020) supplied the worked examples, which makes the session double as a quiet case study in what a maturing analytics function ships in its first five years.

B3: From Strategy to Screens

Hayley Ashby (Norco College), Elmer Yglesias

Ashby and Yglesias treated dashboard development as a governance project, not a design project. Their work at Norco College aligned KPI dashboards directly to the 2030 Strategic Plan and Governance Manual. The session moved through three segments: strategic plan and KPI identification, the methodological work of locking definitions and clarifying denominators, and the emerging dashboard development plan with the District IR/IE Office. The standout phrase from the abstract: dashboards are not plug-and-play. They require clarity, negotiation, and intentional design before a single visual is built.

I2: Designing Narrative-Driven Dashboards

Paulina Krys (Penn State University)

Krys gave the theme its name. Great dashboards do not just look good: they tell a story that compels action. The session laid out narrative-driven design principles applied to research administration data, with specific use cases showing how the principles translate into practice. Common failure modes in dashboard design got direct treatment. The framing fits the broader pattern of the Summit: a dashboard without a story is a chart pile, and chart piles do not change behavior.

I4: It Depends! Building Data Literacy

Laura Beaupre (Northeastern University), Alex Wagner (Emory University)

Beaupre and Wagner addressed the universal problem that every analytics professional eventually meets: stakeholders speak different languages. When a dean says “show our research excellence” or a provost asks “are we competitive,” the analyst’s job is to figure out what decision is actually being made and what data can appropriately inform it. The session covered data literacy concepts directly applicable to research analytics, and the daily-work benefits of investing in shared vocabulary. This is the upstream work that makes every downstream dashboard better.

2. Operational Dashboards in Practice

Sessions in this group presented working systems built at specific institutions. The technical stacks vary (Power BI, Tableau, Smartsheet, SharePoint, Azure), but the design problems rhyme.

A6: Enterprise Data Warehouse and Self-Service Portal

Michelle Duryea (Edith Cowan University)

Edith Cowan University faced the familiar problem of fragmented, inconsistent research performance reporting. The response was a university-wide collaborative project to build the ECU Analytics Portal: a central, self-service platform on SharePoint backed by an Azure-based Enterprise Data Warehouse. The portal provides timely access to research outputs, grants, income, and HDR student supervision data through interactive dashboards and comprehensive documentation. This is the foundational work that I2 and B3 take for granted: without a governed warehouse underneath, narrative-driven design has nothing to narrate.

B5: Data-Driven Award Management

Matthew Kingore (Cayuse), Rachel Marr (Loyola Marymount University)

Pre-award reporting tends to be static, siloed, and reactive. Kingore and Marr presented a case study transforming reporting into actionable analytics for real-time decision-making, anchored in an integrated ERA and reporting framework. The session covered descriptive, predictive, and prescriptive analytics together: visibility, forecasting, workload management. KPI definition, cross-system data integration, and the use of analytics to strengthen sponsor relationships and compliance oversight rounded out the discussion. The vendor-plus-institution co-presentation format gave the session a credibility that pure marketing decks rarely manage.

F4: Automating Expenditure Monitoring With Power BI

Hanin Alhaddad (University of Texas at San Antonio)

Alhaddad walked through the migration of UT San Antonio’s Expenditure Monitoring Report from a multi-sheet Excel workbook with hard-coded formulas and manual year-to-year comparisons into an automated, interactive Power BI dashboard. The dashboard connects to the VPR Server for live data refresh. Leadership now explores trends, projections, and variances through intuitive visualizations and drill-downs. Technical depth was a strength of this session: dashboard design, DAX-driven automation, and forecasting logic all got concrete treatment. This is the kind of unsexy automation work that quietly returns hundreds of analyst hours per year.

G4: Visualizing Faculty Performance Data

Jack Lipton, Nathan Kuhn (Michigan State University), Pam Bach

Michigan State built a home-grown research analytics ecosystem on Power BI. A publication aggregator pulls OpenAlex data and tracks output by author, unit, and college. A centralized Faculty Dashboard visualizes KPIs that go well beyond publications: grant submissions, awards, extramural and institutional salary coverage, all over time. Unit-level trends are superimposed to support real-time benchmarking for faculty, chairs, and deans. Most notably, the dashboard is being used in a piloted annual review process that combines research analytics with user-entered teaching and service data for holistic year-end reports. That is dashboard-as-workflow, not dashboard-as-poster.

C2: Bridging Data Silos With Smartsheet, Tableau, and Power BI

Anna Romanowska-Pawliczek (Stanford University)

Romanowska-Pawliczek tackled a question every analytics leader gets asked and rarely answers cleanly: which tool, when? Her department-led approach assigns roles. Smartsheet is the operational and workflow platform. Tableau handles exploratory analysis and visual communication. Power BI sits as the enterprise layer for integration and governance. The session used a real academic example to show how clarifying each tool’s job avoids the misuse patterns that plague mixed-platform shops. This is the kind of practical guidance that saves teams from a year of architectural drift.

3. Specialized Use Cases

Sessions in this group covered domains where generic dashboard templates simply do not work: compliance, audience tailoring, geospatial reporting, and a set of focused lightning talks.

C1: Research Security Training Compliance Dashboard

Elizabeth Larimore, Laura Lodder (University of Kentucky)

NSPM-33 and the CHIPS and Science Act now require research security training for covered individuals on federally funded projects, with DOE, NNSA, and NSF rollouts in 2025. Larimore and Lodder built a cross-team compliance dashboard tracking completion of these required trainings. The session covered database design that consolidates training records from multiple sources, the role of compliance experts in informing accuracy, transparency, and federal alignment, and a real-time interface for monitoring. This is dashboard work as audit defense, and the timing could not be sharper.

D4: One Dataset, Many Audiences

Taylor Fidler, Carrie Romo (Texas Tech University), Sarah Dasher, Abraham Silva (University of Arizona)

The same data tells different stories to different audiences. Fidler, Romo, Dasher, and Silva compared approaches at the University of Arizona and Texas Tech: flexible reporting frameworks aligning metrics with leadership priorities, user training and consultation, and secure, role-appropriate access. The takeaway is that audience-specific reporting structures meaningfully improve stakeholder engagement and the actual use of data in decisions. The session pairs naturally with I4: data literacy is what lets audience-tailored reporting land.

H2: Geospatial Research Administration

James Geiger (University of Nebraska)

Geiger argued that research administration data is geospatial whether anyone treats it that way or not. Funders and governing bodies are expanding geographic reporting requirements, and most research offices are unprepared. The session covered practical approaches to gathering, visualizing, dashboarding, and analyzing location-based data, with use cases spanning sources of funding, research partnerships, and a novel application of local research expenditure data for central space allocation and expenditure reporting. This was the most unusual angle in the theme, and probably the most underexploited capability for offices not yet investing in it.

B6: Lightning Talks on Practical Analytics, Connectome Tools, and Reviewer Matching

Alex Howard (Pepperdine University), Colin Edwards (OSU Center for Brain Injury Recovery and Discovery), Lori Ann Schultz (Colorado State University), Janki Patel (Columbia University)

Three lightning talks compressed serious work into short slots:

Stacey Croomes (USC) demonstrated Excel-based PI-facing financial dashboards that integrate hit-rate visualizations into monthly reconciliation workflows. Alex Howard (Pepperdine) presented a six-month migration of historical proposals and award data from legacy systems into a unified Cayuse dataset, with a Google Sheets dashboard for senior leadership covering Requested vs Awarded funding, Public/Private mix, and Grants Under Management.

Colin Edwards (OSU Center for Brain Injury Recovery and Discovery) showed an AI-powered Connectome Tool harmonizing siloed datasets (OpenAlex, Semantic Scholar, NIH RePORTER, NSF awards, SBIR/STTR, internal proposal/award/expenditure data) into a forward-looking strategy layer.

Janki Patel (Columbia) walked through a redesign of reviewer matching for internal funding programs after benchmarking Harvard, MIT, Brown, Penn, and Dartmouth. The redesign combines an enhanced taxonomy with AI-assisted methodology.

Three different scales, three different stacks, the same underlying instinct: harmonize the data, then design for the decision.

Key Takeaways

Reading across the thirteen abstracts, four patterns stand out.

1. Definitions before visuals. B3, B5, and G4 all spend serious time on KPI definition, denominator clarification, and federated source coordination. The dashboard is the last step. Institutions that try to build first and define later end up with screens nobody trusts.

2. Audience is a design input, not a footnote. D4, I4, and I2 treat audience analysis as a first-class part of dashboard design. A dashboard for a department chair is not a dashboard for a provost. Pretending otherwise produces tools that get opened once.

3. Live data is the new baseline. F4, A6, and G4 all emphasize live refresh against governed warehouses. The era of static screenshots, monthly Excel exports, and quarterly PDF reports is closing. If a dashboard cannot answer “as of when?” with a precise timestamp, it is already legacy.

4. Specialized beats generic. C1 (compliance), H2 (geospatial), G4 (faculty performance), and B6 (reviewer matching, connectome tools) all show that the most interesting work is happening in domain-specific dashboards where the generic vendor template falls short. The next wave of value is in offices that pick a hard, specific problem and build for it.

If you missed the conference, the two sessions worth seeking out in the recordings are I2 (Krys) for the narrative-design framing that gives the theme its name and G4 (Lipton, Kuhn, Bach) for the most operationally ambitious working system. If you take home one principle, make it this: lock the definitions, know the audience, and only then open the design tool.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: Institutional data governance has moved from policy decks to operating practice. Persistent identifiers are wired into enterprise systems, RIM platforms connect libraries to research offices, research security is being treated as a data problem, and governance councils are answering for AI readiness. Disclosure: I served on the G2 panel.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For years, “data governance” at research universities meant a steering committee, a charter, and a stewardship roster nobody used. At the 2026 Research Analytics Summit, the conversation moved into operations. Sessions across this thread covered governance you can actually point at: persistent identifier infrastructure, RIM systems with named owners, research security as an evidence-driven program, and panels of practitioners trading what works.

Four sub-themes ran across the program: operationalizing governance, cross-unit collaboration and cultural change, the identifier and RIM data layer, and compliance treated as data practice.

Sessions Covered

Grouped by sub-theme:

Operationalizing Governance

Sessions in this group tackled governance as an operating model rather than a policy document, covering what is working across diverse institutions and how governance enables or blocks AI and advanced analytics.

• G2: Panel: Operationalizing Data Governance

• G3: The No One Size Fits All Approach to Implementing Research Analytics

Cross-Unit Collaboration and Cultural Change

Governance fails when units stay siloed. These sessions covered the people work: cross-campus integration, stakeholder engagement, and the cultural shifts that let governance survive a leadership change.

• Day 3 Keynote Panel: Working Across Different Departments

• F5: From Silos to Synergy: Scaling the Research Ecosystem

Identifiers, RIM Systems, and the Data Layer

Governance without a data layer is theater. Sessions in this group showed how persistent identifiers and RIM systems give institutions a substrate worth governing.

• C4: Building Connections: Integrating PIDs, Identity, and Expertise Visibility

• I1: Implementing and Leveraging RIM Systems for Research Analytics

Compliance as Data Practice

Research Security only works as a compliance program if you treat it as data.

• D6: The Data of Research Security

Speakers and Institutions

Speakers from many organizations contributed to this thread of the program.

R1 Research Universities

• University of Kentucky: Dr. Baron Wolf, Billy Clark, ShaRona Lavender, Julie Combs

• Indiana University Bloomington: Willa Liburd

• IU Indianapolis: Olivia MacIsaac

• Oklahoma State University: Clarke Iakovakis

• University of Arkansas: Robert Pilgrim

• University of Florida: Kevin Hanson

• UT Rio Grande Valley: Arya Singh

• Colorado State University: Lori Ann Schultz

• Emory University: Alex Wagner

• Northeastern University: Laura Beaupre

• Virginia Tech: Rachel Miles

• University of Illinois Urbana-Champaign: Mark Zulauf

• Carnegie Mellon University: Jason Glenn

Other U.S. Institutions

• North Dakota State University: Christy Gallagher-Lein

International

• Ontario Tech University: Jennifer Freeman

• Unity Health Toronto: Erica Conte

Industry

• Digital Science: Alexandra Winzeler

Richard Szpara also contributed to G2; institutional affiliation was not in the source program data and is omitted here.

1. Operationalizing Governance: From Charter to Operating Model

Sessions in this group treated governance the way it has to be treated to survive: as an operating model with decision rights, escalation paths, and visible value.

G2: Panel: Operationalizing Data Governance

Robert Pilgrim (University of Arkansas), Kevin Hanson (Chair, University of Florida), Arya Singh (The University of Texas Rio Grande Valley), Richard Szpara, Christy Gallagher-Lein (North Dakota State University)

This was the panel I sat on, so I will keep the framing tight. Kevin Hanson chaired a working session on what governance looks like once it leaves the policy binder. Panelists from four institutions traded what is working, what remains stuck, and how governance maturity enables or blocks the next wave: AI, advanced analytics, and external data sharing.

The throughline: maturity is not measured by the existence of a council. It is measured by whether the council resolves anything, whether stewards have time funded for the role, and whether downstream consumers (analysts, AI tooling, federal reporting) can rely on the artifacts the program produces. Where governance is mature, AI pilots launch faster because lineage is already documented. Where it is not, AI projects stall on data quality questions that should have been answered years ago.

G3: The No One Size Fits All Approach to Implementing Research Analytics

Laura Beaupre (Northeastern University), Erica Conte (Unity Health Toronto), Jennifer Freeman (Ontario Tech University), Alex Wagner (Emory University)

Four institutions, four operating realities: a Canadian comprehensive (Ontario Tech), a hospital research institute (Unity Health Toronto), a private R1 (Emory), and a large private R1 (Northeastern). The panel was structured to be highly interactive, with live polling and open discussion designed to pull perspectives out of the room.

The implicit governance argument: there is no canonical research analytics implementation, and any governance model that pretends otherwise will fail on contact with local context. What transfers is the pattern, not the artifact. The panel was flagged as particularly valuable for REACH network participants.

2. Cross-Unit Collaboration: The Cultural Layer

Governance without working relationships across central units is paperwork. Sessions in this group addressed the cultural and organizational layer directly.

Day 3 Keynote Panel: Working Across Different Departments

Dr. Baron Wolf (Chair), Billy Clark, ShaRona Lavender, Julie Combs (all University of Kentucky)

A keynote panel built entirely from one institution, which is the right design for this topic. Wolf chaired a conversation with peers from central post-award research administration, research analytics and research IT, and central finance and HR data management. The thesis: institutional success depends on units that have historically reported to different vice presidents learning to share data, definitions, and accountability.

The applications named in the abstract were workforce management and breaking down silos. The underlying governance lesson: the hardest data definitions to align are not technical. They are organizational. Whose number is the official headcount, whose number is the official award value, and who decides when those numbers disagree?

F5: From Silos to Synergy: Scaling the Research Ecosystem

Alexandra Winzeler (Digital Science)

Winzeler presented two case studies (Indiana University and the University of Toronto) at different points in the same journey: moving from legacy, fragmented workflows to a connected ecosystem that supports cross-campus decision-making and responsible research evaluation.

The session emphasized that ecosystem implementation is not a software purchase. It is a cultural shift. The technical components (bi-directional integrations, AI-powered workflows, faculty-centric design) only deliver if stakeholder engagement, cross-functional teams, local champions, and a culture of trust are built alongside them. The unified data structure that enables benchmarking is downstream of governance work, not a substitute for it.

3. Identifiers and RIM: The Data Substrate

Governance presupposes a data layer worth governing. Sessions in this group covered the identifier and RIM infrastructure that makes the rest of the program possible.

C4: Building Connections: Institutional Strategies for Integrating PIDs, Identity, and Expertise Visibility

Willa Liburd (Indiana University Bloomington), Olivia MacIsaac (IU Indianapolis), Clarke Iakovakis (Oklahoma State University)

Three case studies on persistent identifier infrastructure: IU Bloomington, IU Indianapolis, and Oklahoma State. The argument: communicating the full scope of institutional research activity requires reliable, interoperable data about scholars, outputs, and impact. PIDs (ORCID iDs in particular) are the infrastructure that makes that possible.

The session covered operational realities: driving ORCID adoption among researchers, connecting PIDs to enterprise systems (HR, sponsored programs, RIM), and using PID-enriched data to surface collaboration networks, disciplinary strengths, and research impact. The framing was deliberately three-dimensional: organizational, technical, cultural. None of those can be skipped.

I1: Implementing and Leveraging RIM Systems for Research Analytics

Olivia MacIsaac (IU Indianapolis), Clarke Iakovakis (Oklahoma State University), Rachel Miles (Virginia Tech), Mark Zulauf (University of Illinois Urbana-Champaign), Jason Glenn (Carnegie Mellon University)

A panel of library professionals whose work sits at the intersection of faculty, research offices, sponsored programs, and academic leadership. RIM systems do not exist in isolation, and library-based administrators see a slice of institutional data flow that nobody else does.

Topics covered the operational realities of RIM administration, integration of Faculty Activity Reports, and patterns of adoption and resistance across faculty populations. The governance lesson is one libraries have understood for a long time: metadata stewardship is unglamorous but it is the floor on which analytics, expertise visibility, and reporting credibility all stand.

4. Compliance as Data Practice

The final session in this thread treated compliance not as a paperwork burden but as a data program.

D6: The Data of Research Security

Lori Ann Schultz (Colorado State University)

Organizations with more than $50M in US Federal R&D funding have been preparing for Research Security program requirements since 2021. Schultz walked through the actual scope: travel, conflict of interest, faculty activity reporting, export control, sponsored programs. That list touches at least five central units, each with their own systems and governance.

The session focused on the data sources that inform compliance, then made the more interesting move: those same sources support proactive monitoring and forecasting. Build the infrastructure to satisfy the federal requirement, then keep using it to manage risk continuously. The compliance program is the floor, not the ceiling.

Key Takeaways

Reading across the abstracts in this thread, four patterns stand out.

1. Governance is judged on operating evidence. Charters and councils are necessary but not sufficient. G2 and G3 both circled the same conclusion: maturity shows up in resolved decisions, funded steward time, and downstream reliability. If your program cannot produce a recent issue it actually settled, it is not yet operating.

2. The data layer comes first. PIDs (C4), RIM systems (I1), and integrated research ecosystems (F5) all show up before governance can do useful work. Institutions trying to govern data they cannot find or trust are set up to fail.

3. Cross-unit alignment is the bottleneck. The Day 3 keynote panel and F5 made the same argument: the hardest definitions are organizational, not technical. Research, finance, HR, and IT each have their own version of every number. Governance work is largely the work of getting those versions to agree, or declaring which is canonical for which decision.

4. Compliance is a forcing function, not the goal. D6 framed Research Security as a data program first. Institutions that build infrastructure to satisfy a federal requirement and then stop have wasted the investment. The same data should be powering proactive risk monitoring long after the compliance review is over.

If you missed the conference, the two sessions worth seeking in the recordings are G3 for the four-institution comparative view and C4 for the clearest articulation of why identifier infrastructure is governance work. If you take home one pattern, make it this: governance is an operating model, not a document.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: Before any dashboard, model, or AI assistant earns its keep, somebody has to extract the data, clean it, and reconcile it. The 2026 Research Analytics Summit treated that work as a first-class discipline. Power Query workshops, SQL primers, crosswalk frameworks, Microsoft Fabric ecosystems, and API automation patterns. Here is the through-line.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For years, ETL and data cleaning at research administration conferences sat at the edge of the program. A vendor demo here, a “tips and tricks” session there. The 2026 Research Analytics Summit moved them to the center. Sessions across the three days dug into the practical mechanics of getting data out of source systems, reconciling messy names, and producing tables that downstream analytics can actually trust.

Three patterns ran through the program: the rise of Power Query and low-code ETL as a baseline skill, the maturity of SQL plus Power BI as a reporting backbone, and the move from manual downloads to API-driven automation. The thread connecting all three is the same: the work that used to be invisible is now the work being showcased.

Sessions Covered

Grouped by sub-theme:

Power Query, Excel, and SQL Foundations

Foundational sessions that build the everyday toolkit: Power Query for repeatable ETL, Excel for transparent reports, SQL for direct access to institutional data, and crosswalks for reconciling messy names across sources.

• WM3: WORKSHOP Power Query 101: ETL for Everyone

• D3: Demystifying SQL: Interpreting and Building Queries for Beginners

• G6: Working Smarter, Not Harder: Excel Shortcuts and Best Practices

• E5: Building a Crosswalk: A Practical Framework for Standardizing Messy Research Data

Pipelines and Platforms at Scale

Sessions that move past the desktop and into institutional pipelines: SQL Server with Power BI for HERD reporting, Microsoft Fabric for unified ingest and storage, and cross-unit collaboration to turn manual rituals into Python-based automation.

• D2: Streamlining HERD Submissions: Leveraging SQL, Power BI, and Campus Engagement for Reliable Reporting

• H6: Building a Modern Research Analytics Ecosystem with Microsoft Fabric

• B2: Tackling Last Minute Requests: Building Research Analytics Expertise Through Cross-Unit Collaboration

Automation and APIs

Sessions in this group on cutting the manual download out of the loop: API-driven collection workflows and SQL Server metadata that documents itself.

• I3: From Manual Downloading to Automated Data Collection with APIs: A Practical Framework for Analysts

• H3: Automating Your Data Dictionary

Speakers and Institutions

Speakers from many organizations contributed to this thread of the program.

R1 Research Universities

• University of Connecticut: Jennifer Lamontagne

• University of Florida: Kevin Hanson, Aaron Johnson

• University of Kentucky: Elizabeth Larimore

• University of Missouri: Sabrina Woo, Kristina Palmer

• Vanderbilt University: Hilda McMackin

Other U.S. Institutions

• Kennesaw State University: Raj Moona

• Seton Hill University: Ying Cao

• Tufts University: Mustafa Humayun, Sarah Marina

International

• None in this thread.

Industry and Consortia

• None in this thread.

Two contributors (Vyvian Tran and Richard Szpara) presented in this thread without an institutional affiliation listed in the source data. The WM3 workshop is described as a joint effort across the University of Missouri, the University of Connecticut, Kennesaw State University, and Arizona State University.

1. Power Query, Excel, and SQL Foundations: The Everyday Toolkit

Most research analytics work still starts with a spreadsheet, a query, or a list of names that do not match. Sessions in this group tackled the foundational skills that decide whether that work scales or stalls.

WM3: Power Query 101, ETL for Everyone

Vyvian Tran, Sabrina Woo (University of Missouri), Raj Moona (Kennesaw State University), Jennifer Lamontagne (University of Connecticut)

A three-hour hands-on workshop on Microsoft Power Query, designed for intermediate Excel users with no coding background. The session covered the Power Query editor UI, basic functions (filter, sort, replace), and intermediate functions (custom columns, combining data from multiple sources). Participants implemented an end-to-end ETL workflow, transforming raw inputs into clean, analytics-ready tables.

The use cases hit the everyday pain points: data cleansing, joining disparate sources, and pulling structured data out of PDFs. The workshop was a joint effort across data professionals at the University of Missouri, the University of Connecticut, Kennesaw State, and Arizona State, which is itself a model worth noting. Cross-institutional collaboration on a shared training asset is rarer than it should be.

D3: Demystifying SQL for Beginners

Jennifer Lamontagne (University of Connecticut), Hilda McMackin (Vanderbilt University)

Lamontagne and McMackin took a deliberately approachable angle: teach SQL using an Excel-based mental framework. The session broke down the basics of interpreting existing queries, understanding query structure, and building queries from scratch without a programming background. Use cases were drawn from day-to-day research administration tasks, with publicly available datasets so attendees could practice afterward.

The goal was modest and well-chosen: comfortable reading and interpreting basic SQL statements. That is the skill that unlocks the next decade of research analytics work for anyone whose institution runs on a relational database, which is most of them.

G6: Working Smarter, Not Harder in Excel

Elizabeth Larimore (University of Kentucky)

Larimore covered two areas that get less attention than they deserve: keyboard shortcuts and tricks to speed up workflow, and best practices for building Excel reports that hold up over time. Specific techniques included locking cell references, linking to underlying data rather than hard-coding values, and structuring formulas so a colleague can audit them in five minutes.

The framing was maintainability for supervisors and leadership. That is the right frame. Most Excel reports outlive the person who built them, and most of them are unreadable by anyone else. Sessions like this are how that changes.

E5: Building a Crosswalk for Messy Research Data

Kristina Palmer (University of Missouri)

Palmer addressed the single most time-consuming task in research analytics: reconciling inconsistent names. Public data sources list universities and funders under variants like “U Missouri” versus “University of Missouri, Columbia,” or “NIH” versus “National Institutes of Health” versus individual institute names. Analysts spend hours per week on this, often invisibly.

The session laid out a repeatable workflow for building reliable name crosswalks using Excel and Power Query: identifying name variants, applying controlled vocabularies, fuzzy matching, transformation rules, deduplication, and lookup-based standardization. Equally important was the documentation discipline: capturing decisions, reducing manual cleanup, and maintaining crosswalks over time so the work compounds rather than resets every quarter.

2. Pipelines and Platforms at Scale: From Desktop to Institutional

Sessions in this group moved past individual analyst workflows and into institutional pipelines that serve the whole research office.

D2: Streamlining HERD Submissions with SQL and Power BI

Kevin Hanson and Aaron Johnson (University of Florida)

The NSF HERD survey is the benchmark for institutional research expenditures, and the submission process is famously painful. Hanson and Johnson walked through the University of Florida’s repeatable approach: a centralized HERD reporting pipeline built on SQL Server ledger views and stored procedures that standardize financial data extraction and enforce HERD business rules.

The pipeline reduces manual effort, supports year-over-year reporting, and (most importantly) enables early identification of data quality issues through recurring SQL error checks deployed throughout the fiscal year rather than at submission time. Power BI dashboards served as active validation tools, surfacing trends, flagging anomalies, and supporting proactive issue resolution. The takeaway: HERD does not have to be a quarterly fire drill if the pipeline is built to validate continuously.

H6: A Modern Research Analytics Ecosystem with Microsoft Fabric

Raj Moona (Kennesaw State University)

Research administration depends on data from multiple systems: proposal submissions, awards, HR, finance, compliance. Moona made the case for Microsoft Fabric as a unified platform that streamlines ingest, transform, store, and deliver across all of them. The session focused on three core capabilities: Dataflows for ETL, Lakehouses for centralized scalable storage, and Semantic Models for consistent enterprise reporting.

Demonstrations covered pulling and transforming data from systems like Cayuse, Snowflake, and SharePoint or OneDrive using low-code automation tools (Dataflows Gen2). Lakehouses provided a single trusted data foundation. Semantic Models standardized KPIs, reduced duplication, and powered dashboards. The closing point landed: many institutions already have Fabric access through existing Microsoft licensing, which makes the cost-of-entry argument harder to ignore.

B2: Tackling Last-Minute Requests Through Cross-Unit Collaboration

Mustafa Humayun and Sarah Marina (Tufts University)

Tufts University’s Research Administration and Development (RAD) office faced a familiar pattern: labor-intensive data tasks under tight deadlines. Identifying active researchers, reconciling name variations, generating reports. Manual work was strangling capacity for higher-value analytics.

The fix was a collaboration with a peer department to build Python-based tools for automating principal investigator data cleaning. The result was rapid production of active researcher lists and a structured dataset that supports advanced analytics: engagement tracking, award expiration forecasting, departmental insights. The session walked through the transformation from manual data handling to a scalable automated pipeline. The framing emphasized cross-unit collaboration: pairing staff with deep research administration knowledge with colleagues skilled in coding, rather than expecting either group to do both.

3. Automation and APIs: Cutting Out the Manual Download

The two final sessions in this thread tackled the most modern shift: replacing manual downloads with code, and getting metadata to manage itself.

I3: From Manual Downloading to Automated Data Collection with APIs

Ying Cao (Seton Hill University), Raj Moona (Kennesaw State University)

Cao and Moona named the bottleneck directly. Manual data collection is error-prone and slow, and it has become the rate-limiting step on a lot of reporting. Their session offered a practical, analyst-friendly framework for automating data collection using APIs.

The workflow covered each step: navigating technical documentation to identify essential components, locating specific data within complex systems, leveraging AI assistants to streamline script development, and validating and transforming raw results into structured analysis-ready datasets. Two case studies anchored the session: Watermark Course Evaluations and Data USA, run across both code-based (Python) and no-code (Power BI) environments. That dual-track demonstration matters: it lowers the barrier for analysts who have not yet picked up a programming language while still showing what is possible when they do.

H3: Automating Your Data Dictionary

Richard Szpara

Szpara covered a small but compounding problem: data dictionaries that go stale the moment they are written. The session showed how to use Microsoft SQL Server’s built-in metadata functionality to add descriptions directly to columns, then surface that information in Tableau so end users see definitions where they consume the data. The talk also briefly touched on equivalent metadata functionality in MySQL and PostgreSQL.

Documentation that lives next to the data is documentation that survives. That is the whole pitch, and it is correct.

Key Takeaways

Reading across the abstracts in this thread, four patterns stand out.

1. Power Query is the new baseline. WM3 and E5 both center on it, and it shows up implicitly across most other sessions. For institutions where Python is not yet a baseline skill, Power Query is the bridge from manual Excel work to repeatable ETL. Expect more workshops like this in the next two years, not fewer.

2. SQL plus Power BI is the institutional default. D2 and D3 both reinforced the point. Whether the use case is HERD reporting or beginner training, the combination of SQL Server for the pipeline and Power BI for the surface has become the assumed reporting backbone for most U.S. research administration shops.

3. The crosswalk problem is not optional. E5 made it explicit, B2 implied it, and every other session brushed against it. Reconciling messy names across systems is the single most expensive task in the field, and the institutions winning at analytics are the ones that treat crosswalk maintenance as a first-class deliverable rather than ad hoc cleanup.

4. APIs and automation beat manual downloads, finally. I3 and H3 both pointed at the same horizon: manual data collection is on its way out, replaced by API-driven workflows and self-documenting metadata. The institutions that get there first will spend their analyst hours on analysis rather than collection.

If you missed the conference, the two sessions worth seeking out in the recordings are WM3 (Tran, Woo, Moona, Lamontagne) for the Power Query foundation and E5 (Palmer) for the crosswalk discipline that pays off everywhere else. If you take home one workflow, make it the crosswalk.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: Competitive funding intelligence has matured from “pull the HERD numbers once a year” into a working discipline. The 2026 Research Analytics Summit showed institutions running ML models on proposal pipelines, mining NIH RePORTER for forward signals, mapping critical-technology partnerships, and benchmarking against named peers using public financial statements.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For most of the last decade, “competitive intelligence” in research administration meant a HERD-table screenshot in a board deck and a wishlist of peer institutions. At the 2026 Research Analytics Summit, the gap between that posture and the state of the art was on full display. Sessions across this thread showed institutions treating publicly available data (NSF HERD, NIH RePORTER, NCSES, IPEDS, GASB-compliant financial statements) as raw material for forecasting, benchmarking, and strategic positioning.

Three threads ran through the program: the federal funding landscape and how to read it before decisions are made, benchmarking that goes deeper than Carnegie tier, and the internal funding plumbing that determines whether any of this intelligence actually moves an institution.

Sessions Covered

Grouped by theme:

Federal Funding Landscape and Competitive Intelligence

These sessions move past after-the-fact reporting toward forward-looking signal extraction: predicting proposal success, mining NIH and HHS budget data, mapping critical-technology partnerships, and structuring formal CI programs.

• A1: Machine Learning Methods for Determining the Likelihood of Grant Proposal Success

• A4: Transforming Data from Noise to Insight for Strategic Planning Purposes

• A5: Critical and Emerging Technologies: Strategic Planning and Partnerships

• E3: From Data to Strategy: A Competitive Intelligence Roadmap for Federal Research Funding

Benchmarking and Research Performance

The benchmarking thread split between standard public datasets (HERD, NCSES, IPEDS) and less-used signal sources (audited financial statements, the SUNDRI survey). Common move: pick a peer set, build a defensible model, monitor over time.

• A2: Benchmarking Research Performance: Analytics for Strategic Insight and Planning

• A3: NSF HERD: Introduction to the Available Dataset and Possible Use Cases

• F3: Research Through the Lens of the SRECNP

• H4: Benchmarking Research Development in the Context of Research Administration: SUNDRI as a Use Case

• H5: Data-Driven Growth Planning Using Benchmarking and Emerging Research Strengths

Internal Funding and Network Analytics

External intelligence is only useful if internal allocation responds to it.

• WM1: WORKSHOP: Repurposing Sponsored Research Data into Actionable Collaboration Network Analytics

• C5: Managing Internal Funding Awards Using the Microsoft Power Platform

Speakers and Institutions

Speakers from many organizations contributed to this thread of the program.

R1 Research Universities

• University of Arkansas: Robert Pilgrim

• University of Nebraska: James Geiger

• The University of Texas Rio Grande Valley: Arya Singh

• University of Missouri-Columbia: Dr. Hansa Magee

• Penn State: Michelle Hutnik

• University of Washington: Melissa Cox

• University of Texas at San Antonio: Hanin Alhaddad

• University of Utah: Jason Lyons

• University of Colorado Denver: Ian Thompson

• Arizona State University: Stacey Goddard

Other U.S. Institutions

• Pomona College: Dean Gerstein

International

No international speakers contributed to this thread of the program.

Industry and Consortia

• Elsevier: Charity Elifritz

• RTI International: Christopher Bennett

• Academic Analytics: Kathy Felts

• Independent / affiliation not listed: Evan Douglas Brooks, Andrew John Tarr

1. Federal Funding Landscape: Reading the Map Before the Money Moves

Federal funding is where most US research dollars come from and where most strategy talk dies on contact with reality. Sessions in this group showed what happens when institutions treat federal data as a forward-looking signal rather than a rearview mirror.

A1: Machine Learning for Proposal Success Likelihood

James Geiger (University of Nebraska), Evan Douglas Brooks

Geiger and Brooks tackled a problem every research-active institution has: proposals take months to receive funding decisions at DHHS and NSF, and leadership wants prioritization signals before the agency rules. Their case study at a Carnegie R1 institution trained ML models on institutional proposal data to estimate funding likelihood, feeding those estimates into prioritization tools for research leadership and regulatory offices.

The most useful part of the abstract is what they admit. The session covers limitations and bias-reduction strategies directly. A model that says “this proposal is unlikely to fund” needs to be defensible, auditable, and clearly bounded, or it becomes a self-fulfilling prophecy.

A4: NIH RePORTER and HHS Budget Data as Strategic Signal

Andrew John Tarr

Tarr’s session is the clearest example of the genre. The premise: publicly available data such as NIH-funded projects and HHS budget requests to Congress already contain enough signal to inform institutional hiring, procurement, budget planning, and research focus. Most institutions just do not extract it.

The session walks through a reproducible ETL approach for NIH RePORTER exports and federal budget data over a ten-year span, with NIH Department categorization and simple checks comparing budgeted versus actual spending. Examples appear in Excel, Power BI, and Tableau, with step-by-step guidance friendly to nontechnical audiences. The right altitude for the audience.

A5: Critical and Emerging Technologies

Charity Elifritz (Elsevier)

Elifritz presented an Elsevier analysis of US and global research positions and industry-academic partnerships in critical and emerging technologies (AI, biotechnology, nuclear, quantum information science, semiconductors). Governments and funders are structuring policy and investment around these categories now, and institutions that can map their own position inside that landscape have a head start.

The move is to use curated bibliometric and partnership data to map innovation landscapes, inform policy, and enable secure strategic research partnerships. The “secure” qualifier is doing real work: institutions need partnership intelligence that accounts for export control and research-security constraints, not just citation counts.

E3: A Competitive Intelligence Roadmap for Federal Research Funding

Hanin Alhaddad (University of Texas at San Antonio), Jason Lyons (University of Utah), Ian Thompson (University of Colorado Denver)

This was the formal-CI session of the program. The team presented a structured approach built through a mentor-mentee program across five states (Colorado, Pennsylvania, Texas, Utah, Virginia). Each mentee mapped its funding profile using NCSES data, identified trends, examined key federal agencies (NIH, NSF, DoD), and benchmarked against named peers.

The output is a replicable roadmap: how to analyze funding data, identify the right peer set, and develop strategies for closing gaps and capturing growth. The session is structured as a methodology, not a result. Other institutions can re-run it on their own data.

2. Benchmarking and Research Performance: Beyond the Carnegie Sticker

Carnegie tier is a starting point. Sessions in this group showed what serious benchmarking looks like once you move past the headline classification.

A2: Research Performance Benchmarking for Strategic Planning

Arya Singh (The University of Texas Rio Grande Valley)

Singh’s session is the strategic-planning frame for the rest of the thread. The session covers how analytics and research-performance indicators support institutional benchmarking, with Carnegie classifications as one application among several. The methodology focuses on identifying high-impact variables, monitoring trends across research expenditures, doctoral completions, faculty activity, and sponsored funding trajectories, and using dashboards, forecasting models, and early-signal indicators.

“Early-signal indicators” is the phrase to underline. The point of benchmarking is not to confirm where you finished last year, it is to flag where the gap is opening.

A3: NSF HERD as the Foundation Dataset

Dr. Hansa Magee (University of Missouri-Columbia), Michelle Hutnik (Penn State)

HERD is the only standardized publicly available dataset that lets you assess the size and characteristics of the US research enterprise. Due January, released November-December. Magee and Hutnik aimed this session at colleagues with little to no prior exposure: history of the survey, what it collects, how to access the data, and the formats it comes in.

The use cases section is where the value lives: benchmarking, institutional strategy and goal-setting, and meaningful metrics. HERD looks straightforward until you compare across institutions with different reporting conventions. For anyone whose institution still treats HERD as a once-a-year submission rather than an analytical asset, this was the right starting point.

F3: SRECNP, Reading Research Through Audited Financials

Stacey Goddard (Arizona State University)

This was the most underrated session in the thread. The Statement of Revenues, Expenses and Change in Net Position (SRECNP, pronounced shrek-nep) sits in every public university’s audited financial statements. Recent GASB rule changes now make it possible to compare SRECNP data across similar public high-research-activity institutions.

Goddard used Arizona State as the worked example, walking through a novice-friendly Tableau data model that surfaces research-related activity over time. The reason this matters: financial-statement data is audited, comparable, and not subject to the self-reporting variability of survey instruments. For benchmarking conversations with a CFO or trustee, this is the dataset that ends arguments rather than starting them.

H4: SUNDRI and the Research Development Office

Dean Gerstein (Pomona College), Christopher Bennett (RTI International)

SUNDRI (Support Networks at Diversified Research Institutions) is the first nationally representative survey on research development in the context of research administration, covering roughly 1,300 doctoral, masters, and baccalaureate institutions, with about 350 responses merged with NSF HERD R&D data and IPEDS data. NSF GRANTED-funded.

Findings cover office structure, organizational placement, staffing levels, titles and experience, turnover, work balancing, applications submitted, and awards processed. An interactive Tableau dashboard enables benchmarking. Up to now, anyone trying to benchmark their RD office relied on informal listserv polls. SUNDRI replaces that with a defensible dataset.

H5: Emerging Research Strengths and Growth Planning

Kathy Felts (Academic Analytics)

Felts closed the benchmarking thread with the action-oriented version: once you understand institutional strengths in core and emerging areas, how do you drive data-driven strategic growth? The frame is comparative data feeding opportunity identification, with proposal development aligned to demonstrated strength rather than aspirational reach.

The discipline this enforces is the right one. Most institutions over-invest in areas where they are already strong, or chase emerging fields they have no foundation in. Comparative data, used honestly, narrows the legitimate target list.

3. Internal Funding and Network Analytics: Where Intelligence Becomes Allocation

External intelligence is only as good as the internal mechanism that translates it into where dollars and attention actually go. Sessions in this group covered the internal side.

WM1: Sponsored Research Collaboration Network Analytics

Robert Pilgrim (University of Arkansas)

Project-based workshop on repurposing existing sponsored research data into network analytics, using Gephi as the primary tool with optional Power BI. The agenda covered an introduction to network analytics for sponsored research, Gephi basics, building proposal networks from provided data, and basic network statistical metrics.

The premise: institutions are sitting on rich relational data (who proposes with whom, across which departments, against which sponsors) that most never visualize. Once you do, questions like “which faculty are isolated, which are bridges, and which collaborations are concentrated in too few people” become legible.

C5: Internal Funding Awards on the Microsoft Power Platform

Melissa Cox (University of Washington)

Cox demonstrated how the University of Washington Vice Provost for Research uses the Microsoft Power Platform (Excel, Forms, Power Automate, Power BI) to manage millions of dollars of internal funding annually, from faculty application through leadership approval. The session is aimed at beginners and walks through automating application/review/distribution, building dashboards for leadership decisions, and illustrating fund distribution across campus.

Why this belongs in the competitive-intelligence thread: internal funding is where institutions place bets on their own future research portfolio. A transparent, auditable, dashboard-backed allocation process is what lets external intelligence shape where money goes. Without it, internal funding gets allocated by relationship and inertia.

Key Takeaways

Reading across the abstracts in this thread, four patterns stand out.

1. Public data is undermined intelligence, not exhausted. HERD, NIH RePORTER, NCSES, IPEDS, and audited financial statements sit in plain view, and most institutions treat them as compliance artifacts. The sessions that turned them into forward-looking signals (A4, F3, E3) were the most differentiated work in the room.

2. Forward signals beat backward ones. A1’s proposal-success modeling, A2’s early-signal indicators, and A4’s budget-versus-actual checks all push the same way: stop reporting last year, start estimating next year.

3. Pick your peer set deliberately. E3’s CI roadmap and H4’s SUNDRI dataset make the same point: the value of benchmarking depends on whether the comparison set is honest. A peer list chosen for ego produces analysis nobody can act on.

4. External intelligence needs an internal allocation mechanism. WM1 and C5 are the connective tissue. If your internal funding is allocated by inertia, it does not matter how good your competitive intelligence is.

If you missed the conference, the two sessions worth seeking out are F3 (Goddard) for the audited-financials benchmarking move and A4 (Tarr) for the reproducible NIH RePORTER pipeline. If you take home one methodology, make it E3’s CI roadmap: it travels.

NOTE: This series was mostly made with AI and in no way are any official products from the REACH Research Analytics Summit. I encourage people to go to the conference site to see more details on sessions linked here The text in this series including the summit themes are AI generated.

TLDR: AI in research administration has stopped being a demo. It is reading proposal guidelines, answering questions against live data warehouses, surfacing risks that dashboards miss, and earning auditable seats next to compliance teams. Here is what the field showed up with this April.

A note on how this was written. This post was drafted with AI assistance from the official conference session abstracts and my personal notes on the sessions I attended. Sessions I did not attend are summarized from the speakers’ published abstracts, not from observation. I have spot-checked the framing and takeaways, but the language and structure are largely AI-generated. Treat it as a curated overview of the program, not a firsthand recap.

The Shift This Year

For the last few years, AI in research administration has lived mostly in slide decks. At the 2026 Research Analytics Summit, that changed. Sessions across the three days showed working systems, real frameworks, and lessons learned from actual implementations. Not “what if?” but “here is what we shipped, and here is what broke.”

Four themes emerged across the program: document intelligence, conversational analytics, readiness frameworks, and the people-and-governance work that holds it all together.

Sessions Covered

Sessions across the three days, grouped by theme:

Document Intelligence

LLMs are being put to work on the dense, lengthy documents that govern research administration: agency solicitations, federal regulations, and policy text. The systems showcased preserve source structure, support citation back to the original, and reduce hours of manual review.

• B1: Enhancing Research Support with Generative AI: The Proposal Guidelines Extraction System

• F1: Lessons Learned from Implementing AI Agents for Higher Education Research Compliance

Conversational Analytics

Natural-language interfaces are starting to replace the ad hoc reporting queue. Both sessions show how a well-governed data foundation can be made directly accessible to non-technical staff through plain-English questions and LLM-generated summaries.

• H1: AI for Research Analytics: Chatting With Institutional Data and Topic-Based Reporting at Scale

• F2: Who Works on Energy? Can Prompt Engineering Turn General Questions Into Actionable Research Intelligence?

Frameworks for AI Readiness

Several sessions move past tool demos to address the harder question: how should an institution prepare for AI adoption? Each offers a portable framework for assessing readiness, surfacing hidden risk, or partnering with vendors to shape platforms from the inside.

• D1: SCALE: A Data-Driven Framework for Building AI Readiness in Research Administration

• E1: Beyond Reporting: How AI-Enabled Research Analytics Reveals Gaps, Risk, and Accountability

• G1: Collaborative Innovation in Practice: Co-Developing AI-Native Research Intelligence

Skills, Governance, and the People Side

Tools fail without the human infrastructure to support them. These sessions cover prompt engineering for analysts, decision frameworks for choosing between AI and traditional methods, and the governance work that determines whether any pilot survives.

• WM2: WORKSHOP: Getting More From Microsoft Copilot: Prompting and Agent Design for Research Analytics

• WA3: WORKSHOP: AI4RA, the Intersection Between AI and Data

• I6: Lightning Talks on Metrics and Governance

Speakers and Institutions

Speakers from many organizations contributed to this thread of the program.

R1 Research Universities

• University of Idaho: Barrie Robison, Nathan Layman

• University of Illinois (Urbana-Champaign): Dan Harmon, Chandni Mathur

• University of Missouri: Kristina Palmer, Sabrina Woo

• Oklahoma State University: Clarke Iakovakis, Matt Upson

• University at Albany (SUNY): Aidai Kokonova

• University of Colorado Boulder: Lisa Nanstad

• University of Florida: Ronald Fick, Alina Zare

• Northern Arizona University: Nihal Sarikaya

Other U.S. Institutions

• Morgan State University: Ayomide Ajibola

• Southern Utah University: Nathan Wiggins

• Chapman University: Douglas Dechow

International

• Loughborough University (UK): Dr. Elizabeth (Lizzie) Gadd

Industry and Consortia

• Clarivate: Christiane Gannon

• Universities Research Association: Kimberly Schramm

1. Document Intelligence: AI Reads What Nobody Wants To

NSF, NIH, and DOE solicitations are dense, long, and unforgiving. Sessions in this group showed working systems that finally make those documents tractable.

B1: The Proposal Guidelines Extraction System

Chandni Mathur and Dan Harmon (University of Illinois)

Mathur and Harmon presented a full-stack generative AI solution that ingests an agency PDF, extracts its text while preserving structural hierarchy, and uses a Large Language Model to automatically identify key elements such as deadlines, budget limits, eligibility, and submission requirements. The extracted components are surfaced in a clean interface alongside the original document, with linked navigation so a reviewer can jump straight from a flagged data point to its source paragraph.

The session walked end-to-end through design and implementation: text extraction, prompt engineering, frontend, and database architecture. They also covered configurable data element definitions and search-and-filter functions, both of which signal the system is intended as reusable infrastructure rather than a one-off prototype. The framework generalizes beyond proposals to any administrative or document-intelligence workflow.

F1: AI Agents and an MCP Server for Federal Compliance

Sabrina Woo (University of Missouri), Nathan Layman (University of Idaho)

The University of Missouri and the University of Idaho teamed up on what may be the most operationally important AI session of the summit. The problem they tackled: research administrators need auditable access to Uniform Guidance, but chatbot answers of unknown provenance can be outdated or non-citable, creating real compliance risk.

Their solution is a locally hosted Model Context Protocol (MCP) server that supplies federal policy text from the electronic Code of Federal Regulations (eCFR) directly to AI agents. The result is reliable, current, and citable answers grounded in the actual source. The session walked through extracting eCFR text, the core components of an MCP server, and lessons learned from a real deployment, with example Python code published in a public repository.

That is the difference between a toy and a tool.

2. Conversational Analytics: Chatting With Your Data Warehouse

This was the breakout category. Sessions in this group showed how natural-language interfaces are starting to replace the ad hoc reporting queue that consumes so much research office time.

H1: Chatting With Institutional Data and Topic-Based Reporting at Scale

Dan Harmon (University of Illinois), Ronald Fick and Alina Zare (University of Florida)

Harmon, Fick, and Zare demonstrated two complementary capabilities running on top of a well-governed research data warehouse.

The first is a conversational analytics layer. Users ask plain-English questions about proposals, awards, and expenditures. The system translates the question into SQL, runs it against live data, and returns results that can be refined through follow-up questions or exported. No dashboard, no ticket, no week of waiting.

The second is LLM-assisted topic-based reporting at scale, built with the University of Florida’s UF NaviGator Toolkit. The prototype generates reusable rollups for the standing leadership questions: awards by research area, funding by sponsor, active investigators, time-bounded trend snapshots. The session covered prompt and pattern design, evaluation approaches, and how to enable non-technical staff to self-serve through guided no-code workflows.

The blueprint they handed the room: a governed data foundation plus a thin AI layer beats a thick AI layer on top of nothing.

F2: Prompt Engineering for Research Intelligence

Clarke Iakovakis and Matt Upson (Oklahoma State University)

Iakovakis and Upson focused on a narrower question that every research office has actually been asked: when a legislator wants to know “who works on energy at this institution,” how fast can you answer with a citation-ready brief?

Their tool runs a structured prompt framework over thousands of publication records from their RIM, including bibliographic metadata, abstracts, and institutional affiliations. It identifies topically and semantically relevant research, generates narrative syntheses aligned to strategic priorities, and produces briefs suitable for external stakeholders. The lessons-learned portion of the talk centered on the balance between automation and human oversight, and how to keep methodological rigor intact when an LLM is doing the synthesis.

3. Frameworks: Moving Beyond “We Tried Some Prompts”

Sessions in this group tackled the readiness question head-on.

D1: SCALE, a Framework for AI Readiness

Aidai Kokonova (University at Albany)

SCALE is a five-step roadmap: Scan landscape and process needs, Collect & Curate high-value data and scattered knowledge, Align & Architect solutions that integrate policies and workflows, Launch & Learn through iterative pilots, and Evaluate & Expand using measurable indicators of value and adoption.

What makes SCALE useful is what it deliberately is not. It is not a model-selection guide. It is not a vendor evaluation matrix. It is a framework for the unsexy data and process work that determines whether any AI implementation actually scales. Kokonova used GrantsMate, an AI partner for research success, as the worked example throughout. The framework is technology-agnostic, which is the right call for a field that is going to churn through three model generations in the next eighteen months.

E1: Beyond Reporting, the Gap-Risk-Accountability Framework

Ayomide Ajibola (Morgan State University)

This was the most pointed reframing of the conference. Ajibola argued that research administration analytics has been stuck in a reporting paradigm. Activity goes up, dashboards turn green, leaders get briefed. Meanwhile, gaps go unmonitored, risk stays unsurfaced, and assumptions remain unverified.

Her Gap-Risk-Accountability framework asks three diagnostic questions of any analytics output:

• What data is missing or inconsistent that could change the conclusion?

• What early risk signals are not being escalated?

• Where is accountability for unmonitored vulnerabilities unclear?

She used institutional examples (including Morgan State during a period of rapid research growth) to show how strong activity indicators can coexist with serious unseen vulnerabilities. AI in this framing is an analytical assistant, not an automation engine, with humans firmly in the loop on every diagnostic check.

G1: Co-Developing AI-Native Research Intelligence

Christiane Gannon (Clarivate), Lisa Nanstad (University of Colorado Boulder)

Gannon (Clarivate) and Nanstad (CU Boulder) walked through what it actually looks like for an institution to shape a vendor platform from the inside. The platform in question is Web of Science Research Intelligence, an AI-native solution integrating publications, patents, grants, policy documents, and clinical trials into a single evidence base for research strategy.

Nanstad’s portion was the more interesting half. She covered why CU Boulder became a development partner, what the institution actually contributed, and how that input shaped the product. She also discussed early value realized, adoption planning, and advice for peer institutions considering similar partnerships.

The takeaway was less about the product and more about the model: institutions that get the most out of AI-native tools are the ones that helped build them.

4. Skills, Governance, and the People Side

Tools without skills go nowhere. The remaining sessions covered the human infrastructure.

WM2: Microsoft Copilot for Research Analytics

Kristina Palmer (University of Missouri), Nihal Sarikaya (Northern Arizona University), Dan Harmon (University of Illinois)

A hands-on workshop on prompt engineering tailored to research analytics, not generic productivity. Topics included structured and multi-step prompting, landscape scanning, benchmarking, structured summaries, basic quantitative analysis, and reusable prompt templates. The session also covered how to design and deploy Copilot agents for recurring tasks. The framing throughout: Copilot as a support tool that gets analysts to insight sooner, not a replacement for analytical judgment.

WA3: AI4RA, the Intersection Between AI and Data

Nathan Wiggins (Southern Utah University), Barrie Robison and Nathan Layman (University of Idaho)

A workshop drawing on lessons from the AI4RA NSF GRANTED project. Participants explored how AI and data science complement each other, where each contributes to decision-making, and where human expertise remains essential. Practical guidance focused on distinguishing tasks best suited for AI-powered approaches versus those better handled with traditional data science methods. Attendees got hands-on access to a temporary demo of Vandalizer, an AI-powered research administration tool.

I6: Lightning Talks on Metrics and Governance

Kimberly Schramm (Universities Research Association), Douglas Dechow (Chapman University), with Dr. Elizabeth (Lizzie) Gadd (Loughborough University) chairing

Two lightning talks closed the AI thread of the conference:

• Schramm (Universities Research Association): From Data to Insights, Research Metric Utilization at a National Lab.

• Dechow: Advancing AI Implementation and Governance in Research Administration at Emerging Research Institutions.

This is the unglamorous policy, oversight, and adoption work that decides whether any pilot becomes a program.

Key Takeaways

Reading across the abstracts in this thread, four patterns stand out.

1. The foundation question is back. Every working AI demo described in this thread of the program sits on top of something real: a governed data warehouse, a curated RIM, a structured document corpus. Institutions that have not done that foundational work cannot skip to the AI layer.

2. Diagnostic beats descriptive. E1 sets the bar. Reporting what happened is no longer enough. The interesting AI work surfaces what the dashboard missed. Expect more institutions to reframe analytics demand from “build me a report” to “tell me what I am not seeing.”

3. Auditable wins. MCP servers, citation-linked extractions, and human-in-the-loop checks appear across multiple sessions. The era of unprovenanced chatbot answers in compliance contexts is ending. For anyone who has to defend a number to a federal auditor, that is good news.

4. Frameworks matter more than tools. SCALE, Gap-Risk-Accountability, and the AI4RA decision framing all give attendees something portable. Tools change every quarter. The frameworks are what survive the next model release.

If you missed the conference, the two sessions worth seeking out in the recordings are E1 (Ajibola) for the diagnostic reframe and F1 (Woo, Layman) for the auditable-by-design implementation pattern. If you take home one framework, make it SCALE.

Who am I

• Robert Pilgrim, Ph.D. | rpilgrim@uark.edu

• Associate Director of Data Strategy Insight

• Office of Sponsored Programs, UARK

• B.Sc Astrophysics | Ph.D. Space Science

• My Website rpilgrim.com | LinkedIn) | Substack

Purpose of these Webinars

• Met many people:

  • Conferences / Summits

  • Workshops / presentations

  • REACH mentoring

• Most people just need help starting
  

A Note on Data

• BIG friction “no data access”

• Dummy data or public data (ASU)

• No direct system access needed

• Federal: HERD, IPEDS, SBIR/STTR

• Let’s get started...
  

Session Framework

Simplified Data Workflow

Power BI Desktop

• 100% Free, no restrictions

• Why need a license?

• Publishing, sharing, collaboration
  

Power BI Service

• Cloud based

• Share / Collaborate

• Microsoft campus?

• app.powerbi.com

Power Query Get Data

• Wide range of data sources

• Same cloud / desktop / Excel

• Code / No-code

Power Query Transform your Data

• Connect , Clean, Transform and Merge

• Code directly or GUI

• Python, R and SQL

The Data Model

• Relationships NOT merging

• Similar to SQL relationships

• Handles very large data

• Powered by Data Analysis Expressions (DAX)

Data Analysis Expressions (DAX)

• Data Models = BRAINS | DAX = LOGIC

• Powerful language

• Not coding, it is an expression language

• Built for cross-data analysis

• Examples later
  

Core DAX Function Groups

• DAX function reference

• We write DAX later

• Date and Time

• Filter

• Time Intelligence
  

Deployment Models

• Single report does everything

• NOT scalable, breaks easily

• SPLIT into 2 buckets

• Data Models | Reporting

Is it Time to Split the Data model from the Report?

• Multiple reports, same data?

• Easy to refresh?

• What if data source changes?

• Local files or cloud?

The Data Model as Foundation

• The Brain (Remember connect not merge)
  

Reporting Layer

• Multiple reports, one data model

• Same data, different story

  • Executive

  • OSP Director

  • Department Head

  • Grant Specialist

Deploying Reports

• Report >> Users

• Quick one-off share?

• How many users?

• Need to download data?

• Draft or production?

Deployment Options

Power BI Service Workflow

• Desktop >> Workspace >> Service >> APP >> Mobile

• Primary way to share

• Workspace: Staging area, build and test

• Apps: Polished reports for end-users, access control

• Mobile: Apple and Android

Let’s Build a Report

• Any questions?

• This report will be used each session

• Download file and data here

• Final file: XXX

The Data

• Dummy proposals data

Demo Live

• Page-1

  • Replicate the tables on the left

• Page-2

  • Expandable table

  • Filter improvements

• Page-3

  • Additional visuals from store

Live Demo Page 1

Live Demo Page 2

Live Demo Page 3

Listen to a 90 Second overview below or click here for 30 minute deep-dive

Overview

A well-structured file system establishes the substrate: durable, portable, AI-readable data. But a well-structured file handed to an AI cold still produces generic output. The model lacks the interpretive layer required to reason about your work in context.

That gap has a structure. Think of it as a stack. Each layer is a prerequisite for the one next to it. Skipping layers does not accelerate output, it degrades quality in ways that are easy to misdiagnose as model limitations.

The Layers

Layer 1: Purpose
Define what this workspace is for. Strategic planning, faculty development, research development, compliance, institutional reporting: each carries different reasoning requirements. Without an explicit purpose definition, the model defaults to generic reasoning. This is the load-bearing layer everything else depends on.

Layer 2: Organizational Identity
Who is asking, in what role, within what institutional structure? This encodes your unit’s mandate, reporting relationships, and key stakeholders, whether that is a VPR, provost, faculty governance body, or federal sponsor. It allows the model to interpret the same question differently depending on where it is being asked from.

Layer 3: Strategy
What direction is your unit moving? Current priorities, multi-year initiatives, known constraints and competing pressures. Without this layer, the model evaluates options against generalized best practices rather than your actual criteria. This is what separates strategic reasoning from informed noise.

Layer 4: Current Data
Live institutional information: active initiatives, workforce data, benchmarks, draft documents, survey results, budget snapshots. This is where FILE pays off directly because your data is already in a format the model can parse. At this layer, AI shifts from general advisor to analytical partner operating on your actual situation.

Layer 5: The Query
Only here does prompt quality become the primary performance variable. A precise query on a fully loaded stack produces fundamentally different output than the same query on an empty context. Most users are optimizing this layer while the four beneath it remain unbuilt.

What This Looks Like in Practice

Note: The following examples are AI-generated illustrations.
The structure is identical across every role and function. The foundation layer, identity, strategy, data, and work are constant. Only the content inside each file changes. Three examples illustrate the point.

A HERD Survey Analyst

The decisions.md file carries particular value here. HERD is full of judgment calls: how you classify interdisciplinary expenditures, how you handle cost sharing, how you aggregate agency codes. Logging those decisions means next year’s submission starts with institutional memory already loaded rather than rebuilt from scratch.

/division-research-innovation/
│
├── PROJECT.md                            ← Purpose: HERD survey
│                                       preparation and submission
├── /about/
│   ├── about-business.md            ← DRI mandate, NSF relationship,
│   │                                   survey obligations
│   └── about-you.md                 ← Your role, data access,
│                                       key contacts
├── /strategy/
│   └── strategy.md                  ← NACUBO mapping, F&A methodology,
│                                       prior year decisions
├── /data/
│   └── current-data.md              ← Expenditures by source, discipline
│                                       codes, peer benchmarks
└── /work/
    ├── /herd-2026/
    │   ├── project.md               ← Scope, timeline, contacts
    │   ├── tasks.md                 ← Open items, deadlines
    │   ├── decisions.md             ← Classification calls, edge cases,
    │   │                               methodology changes
    │   └── log.md                   ← Anomalies, coordinator updates
    └── herd-status.md               ← AI-generated readiness brief

A VP of Faculty Affairs

/faculty-affairs-vp/
│
├── PROJECT.md                    ← Purpose, orientation
├── /identity/
│   ├── office-overview.md           ← Mandate, scope, authority
│   ├── stakeholders.md              ← Provost, deans, faculty senate
│   └── governance.md                ← Policy ownership, committees
├── /strategy/
│   ├── priorities-2026.md           ← Retention, equity goals
│   ├── initiatives.md               ← DEI programs, policy reform
│   └── constraints.md               ← Budget limits, union agreements
├── /data/
│   ├── faculty-demographics.md
│   ├── promotion-pipeline.md
│   ├── retention-risk.md
│   └── compensation-benchmarks.md
└── /work/
    ├── /policy-review-2026/
    ├── /faculty-leadership-program/
    ├── /promotion-cycle-2026/
    └── weekly-briefing.md

A Director of a Newly Formed Industry Partnership Hub

A newly formed hub will make a lot of foundational calls early: what sectors to prioritize, how to structure tiered partnerships, what a university brings versus what an industry partner expects. Logging those decisions in decisions.md means institutional memory survives staff turnover and the reasoning behind early choices stays accessible as the hub scales.

/innovation-hub/
│
├── PROJECT.md                            ← Purpose: establish and operate
│                                       a new collaboration and industry
│                                       partnership hub
├── /about/
│   ├── about-business.md            ← Hub mandate, university backing,
│   │                                   founding charter, success metrics
│   └── about-you.md                 ← Your role, decision authority,
│                                       key relationships
├── /strategy/
│   └── strategy.md                  ← Partnership model, target sectors,
│                                       engagement pipeline, revenue goals
├── /data/
│   └── current-data.md              ← Active partner conversations,
│                                       MOU status, space utilization,
│                                       pipeline metrics, peer benchmarks
└── /work/
    ├── /partner-pipeline/
    │   ├── project.md
    │   ├── tasks.md
    │   ├── decisions.md             ← Partnership terms, exclusivity
    │   │                               calls, tier structure decisions
    │   └── log.md
    ├── /hub-launch/
    │   └── project.md
    ├── /programming/
    │   └── project.md
    └── weekly-briefing.md           ← AI-generated pipeline summary

File Reference

These are the core files you need for each project, preferably as Markdown (.md) files.

• PROJECT.md -Purpose and orientation of the workspace. Tells the AI what this context is for before anything else is loaded.

• about-business.md - The institutional or organizational context. Mandate, structure, reporting lines, key obligations.

• about-you.md - Your personal context. Role, decision authority, working style, key relationships.

• strategy.md -Current direction. Active priorities, multi-year goals, known constraints, approach and methodology.

• current-data.md - Live snapshot of where things stand right now. Metrics, benchmarks, active portfolio, current state.

• project.md - Scope and goals for a specific project. What it is, why it exists, who is involved.

• tasks.md -Current task list. Open items, owners, deadlines, status.

• decisions.md - Log of key decisions made. What was decided, why, and by whom. Institutional memory.

• log.md - Running narrative of progress. Updates, blockers, anomalies, meeting notes.

• weekly-briefing.md - AI-generated summary pulled from the work folder. Status, risks, priorities, next steps.

The Operational Implication

The Context Stack is not a one-time setup. It is a design principle for how you can move to an AI-First workflow. Central to that workflow is the concept of a context artifact: any pre-built, reusable document that AI can load and reason from.

Drop these files in you AI chatbot of choice to start using this workflow

Orientation documents, strategic briefs, and current-state snapshots are all context artifacts. Build them once, and they eliminate the need to re-explain your situation at the start of every session. Loading them collapses the distance between institutional knowledge and AI output.

The Context Stack tells AI what to do with it.

The units that extract durable value from AI will not be those with the best prompts. They will be the ones that treat institutional context as infrastructure.

A good prompt is necessary but not sufficient. AI also needs to understand who you are, where you sit institutionally, and what you are working with right now. The Context Stack is a five-layer architecture that bridges your data foundation to actionable AI output, applicable across any function in a university research enterprise.

In the previous post, i argued that an AI-First workflow requires operational work to live in open Markdown files.

Here’s a concrete example video

On the left of the video: Raw Markdown task list.
On the right of the video: Kanban board generated from that same file using an Obsidian plugin. Obsidian is a free Markdown based program.

There is no separate database. No synchronization. No export step.

The board is just a visual layer. The Markdown file is the system of record.

NO FRICTION for AI

Why This Matters

Because the tasks live in plain text:

• AI can read and write directly to the source.

• It can scan every project folder in seconds.

• It can aggregate active tasks across projects.

• It can generate weekly summaries automatically.

• It can build cross-team views on demand.

  Work within the limitations of your authorized AI tech stack by changing to an AI-First workflow. All data is stored locally.

  

No APIs.
No vendor lock-in.
No integration friction.

AI doesn’t need access to your app.

It needs access to your files.

Next Steps

Get Obsidian for free here (or VS Code if you already have it)

Install the Kanban Plugin

Designing Task Files That Support Automation and AI Collaboration

TL;DR: Most task tools store your work inside proprietary databases. Markdown stores tasks as structured text files you control. Using simple checkbox syntax and headings, a single Markdown file can function as a Kanban board, render into multiple views, and remain portable across tools.
When tasks exist as structured files, AI can read, summarize, and update them directly without fragile integrations or export loops.

Overview

Most task management software locks your work inside proprietary databases.

You do not own the structure. You only interact with it.

Markdown offers a different approach. Tasks become structured text files that you control, version, move, and render into interfaces when needed.

Files first. Interfaces second.

This is not a productivity tweak. It is an architectural decision.

This post covers:

1. How tasks are represented in Markdown

2. How that structure maps to Kanban workflows

3. Why structured text becomes strategically important when layered with AI

This illustration shows an AI maturity model and the shift from standalone chat tools to systems operating directly on structured files, learn more here https://researchanalytics.substack.com/p/ai-feels-useless-because-it-cant

Tasks as a Text-Based Data Structure

A Markdown task is a predictable structural pattern.

Checkbox Syntax

- [ ] Open task
- [x] Completed task

Brackets define state.
Text defines the payload.

Subtasks are created through indentation:

- [ ] Parent task
    - [ ] Child task

Example:

This provides a minimal state model:

• Boolean completion

• Hierarchical nesting

• Ordered grouping

No database required.

Using Headings as Workflow States

Markdown headings introduce hierarchy.

# Project Name
## Pending
## Doing
## Done

Example:

Headings act as containers. In practice, this functions as a lightweight Kanban model:

• Each heading represents a column

• Tasks inherit the state of the heading above them

• Moving a task between headings changes its status

The structure is both human-readable and machine-parseable.

Rendering: Interface as a Layer

When opened in a Markdown-aware tool, the file can render as a visual board.
Example using Obsidian with a Kanban plugin:

Headings become columns. Tasks become draggable cards.

Drag-and-drop updates the underlying Markdown file. The source remains plain text.
The same file can render as:

• Outline view

• Table view

• Kanban view

The interface changes. The file remains stable.
Separating data from interface is the core design principle.

The Architectural Advantage of Files

Storing tasks as Markdown provides:

• Tool independence

• Optional Git-based version control

• Cross-project searchability

• Long-term durability

• Easier migration

• No AI friction

More importantly, it creates structured surface area that AI systems can operate on directly.

A proprietary task database requires API integration.
A Markdown task file is immediately readable as text within your authorized environment.

Knowledge workers dream or nightmare? When AI has visibility into your workflows, it becomes operational, not conversational.

Layering AI on Top of Structured Task Files

With structured text, AI interaction becomes straightforward.

An AI system can:

• Parse headings as states

• Count incomplete tasks

• Detect overdue items if timestamps exist

• Summarize by section

• Generate reports across multiple files

For example: “Scan all project task files. List open tasks grouped by project. Identify items moved to Done this week. Generate an executive summary.”

If tasks live in separate app silos, this requires multiple integrations, if tasks live in structured files, it is direct text processing.
This model can be described in four layers:

Foundation: Structured Markdown task files
Intelligence: AI systems with read and write access
Logic: Naming conventions and folder standards
Experience: Rendering tools and plugins

Consistency is critical. Automation depends on predictable structure.

A detailed description of this framework is available here:
https://researchanalytics.substack.com/i/187284329/the-file-framework

The AI Parallel: Where We Actually Are

The current state of AI adoption resembles early computing.

(Source:
https://softwareg.com.au/en-us/blogs/computer-hardware/history-of-computer-hardware-timeline?srsltid=AfmBOoorqtVSWJ4OnFJnj_g2ivdRz8cL-hrr9_JWuTovk2tFDSOGOu7-)

Early computers were powerful but isolated. Scale came from standardized operating systems and file systems.

Today, many professionals use AI daily but only through chat interfaces. That is comparable to early computing before standardized file layers.

The breakthrough in computing was structured, portable foundations.

The same principle applies here, if tasks remain inside proprietary systems, AI remains peripheral. If tasks exist as structured files, AI becomes operational.

Getting Started

1. Create a .md file (or even just a .txt file) for a project.

2. Define workflow states as second-level headings.

3. Add tasks using checkbox syntax.

4. Store the file in a shared or version-controlled repository.

5. Use a Markdown-aware editor to render views.

6. Introduce AI summarization once structure is stable.

Start small. Enforce consistency. Avoid premature complexity.

You can drag and drop a Markdown file directly into your AI system and begin querying it.

This also works with Word documents or exports from other tools. Each conversion step adds friction.
The objective is direct access to source files.

No copy-paste loops. No intermediary formats. No proprietary lock-in.

Structured text becomes the system of record.

Conclusion: Files First

Markdown does not replace enterprise tools overnight. It establishes a portable layer beneath them.

In early computing, progress came from standardized file systems and durable abstractions that separated data from interface.

AI is at a similar stage. Many professionals use AI. Few have redesigned workflows so AI can operate directly on core artifacts.

Build the foundation first.

If tasks live inside proprietary databases, their is too much friction between you and AI. If tasks live as structured files, AI becomes an operational layer.

The shift is not about better prompts, it is about better foundations.

Markdown Task

Here are the task used to make the images in this blog post, copy/paste them into the markdown editor of your choice.

## Phase 1: Foundations & Data
- [x] **Gather Report Requirements**
	* [x] Define KPIs and target audience
	* [x] Identify data sources (SQL Server, Excel, API)
- [x] **Data Architecture**
	* [x] Establish Power Query transformation logic
	* [x] Create Date Table (DAX or M)
- [ ] **Security Mapping**
	* [x] Define Row-Level Security (RLS) roles
	* [ ] Map users to security groups in Entra ID
## Phase 2: Design & Build
- [x] **Data Modeling**
	* [x] Build Star Schema (Facts and Dimensions)
	* [x] Create Core Measures (Total Sales, YoY Growth)
- [ ] **Report Visualizations**
	* [x] Create "Executive Summary" landing page
	* [ ] Build "Drill-through" detail pages
	* [ ] Apply corporate branding and color themes
## Phase 3: Deployment Pipeline
- [x] **Deploy to Development**
	* [ ] **Deploy to Test**
	* [ ] Validate data refresh schedules
	* [ ] Set up Gateway connections
- [ ] **Deploy to Production**
## Phase 4: Enablement
- [ ] Create "Data Dictionary" for business terms
- [ ] **User Documentation**
- [ ] Record 5-minute "How to Navigate" video
- [ ] **Final Sign-off**

Power BI analytics has become too complex for informal documentation and basic file versioning. The PBIP format exposes report logic as text, making real version control possible. GitHub provides a clear history of changes, decisions, and ownership, even for solo analysts. Because it is text and Markdown based, it also integrates cleanly with modern AI tools. Together, Power BI and GitHub bring software grade discipline to higher ed analytics without turning analysts into software engineers.

Leveraging GitHub with Analytics Reporting

Overview

As discussed in this post, university analytics teams can learn a great deal from software developers. Software teams routinely manage hundreds or thousands of lines of logic while maintaining documentation, version control, and a clear record of decisions.

The core question is straightforward. How do large groups of people work on the same system without losing track of changes, intent, and ownership?

GitHub is the industry standard answer. While many higher ed analysts do not consider themselves software developers, the overlap between analytics work and software development is substantial.

Version Control Without GitHub

Most analytics teams already use a form of version control without realizing it. Every time a file is saved to OneDrive or Google Drive, a new version is created. This allows basic rollback and recovery.

That approach works at the file level, but it breaks down when you need to understand how logic changed over time or why a decision was made.

Power BI Project Format (PBIP)

Historically, Power BI stored everything in a single PBIX file. Data, transformations, the model, calculations, and metadata were bundled together. This made meaningful version control nearly impossible.

The PBIP format changes this by breaking the report into a structured folder.

There are four main components. The data itself is stored in the fourth folder under .pbi, which acts as a local cache. GitHub does not upload this data. Only the report structure and logic are tracked.

All elements of the PBIP format are human readable text. This makes them suitable for inspection and version control. This approach is consistent with modern Microsoft file formats. If you have ever renamed a .docx file to .zip, you have seen the same underlying structure.

GitHub Integration

The simplest way to get started is GitHub Desktop. While command line tools are available, GitHub Desktop lowers the barrier significantly.

You will need a GitHub account. Many institutions already have higher education agreements that support single sign on. If not, a personal account works. No data is stored in GitHub, only the report structure.

Even for solo analysts, this setup is valuable. GitHub provides history, accountability, and documentation by default.

Instructions for connecting a local PBIP folder to GitHub are available here:
Adding a repository from your local computer to GitHub Desktop

GitHub tracks text changes over time. To the user, it looks like a normal folder. Behind the scenes, GitHub records:

• Which files changed

• What lines were added, modified, or removed

• When the change occurred

• Who made the change

Each sync, or commit, includes a short description such as “Updated ROI calculations.” Commits can also be linked to issues. When an issue is referenced, it is automatically closed, creating a direct connection between tasks and changes.

Saving Power BI Reports as PBIP

Saving reports in PBIP format must be enabled in Power BI preview settings. Publishing to workspaces works the same way as before.

When first enabling this feature, creating backups is strongly recommended, especially if you are using deployment pipelines.

Conclusion

Higher ed analytics has outgrown informal documentation and file based versioning. As complexity increases, the cost of lost context rises quickly.

GitHub addresses this directly by providing a clear, auditable history of changes and decisions. With PBIP, analytics logic is no longer trapped in opaque files. It becomes visible, reviewable, and manageable.

This workflow is not only for large teams. Even if you are a team of one, GitHub becomes your documentation, change log, and long term memory. It reduces rework today and lowers the cost of collaboration tomorrow.

Because GitHub is Markdown and text based, it also integrates naturally with modern AI tools that operate on structure and context. As analytics and automation continue to converge, this is a meaningful advantage.

This is not about turning analysts into software engineers. It is about using the right infrastructure for complex analytical work.

TLDR: AI feels underwhelming because your work is trapped across too many disconnected tools. The next wave of value comes when AI can operate directly on structured work data.

AI Feels Useless Because Your Work Is Locked Away

If AI is truly as “magical” as they say, why haven’t your own efforts to use it been impressive? Why does it feel like more fuss than it is worth?

Let’s be honest: this image is a typical week for most people whose job happens on a laptop. Emails. Meetings. Spreadsheets. Logins. Status updates. Repeated follow-ups.

How can AI help us right now, using what we already have access to today, within the confines of organizational security protocols?

Here is the core problem.

Most knowledge work is fragmented across too many tools that do not talk to each other. The work you need is buried behind logins, dashboards, and scattered files.

AI is not failing because it is weak.

AI feels weak because it cannot see your work.

The FILE Framework

To build an AI-ready productivity system, we use the FILE framework. It is a personal layer that complements official systems of record, not a replacement for them.

F: Foundation (The Filesystem)

Your work lives in folders of plain-text Markdown (.md) files for notes, tasks, and logs.

I: Intelligence (The Models)

LLMs reason over your foundation. Today it might be GPT-4o or Claude. Tomorrow it will be something else.

L: Logic (The Orchestration)

This is where automation lives. It turns daily logs into weekly updates, extracts tasks, and flags project risk.

E: Experience (The Interface)

This is how you interact with the system: Obsidian, VS Code, or any other editor. The interface is interchangeable.

Why Markdown Works

Markdown is a practical interoperability layer, it is a simple text based file format, much the same as a .txt file but with well defined formatting standards for things such as headings, tables, links etc.

https://www.markdownguide.org/getting-started/

It is readable for humans, easy for machines to parse, and stable over time.

It also avoids a core problem with most productivity systems: your work becomes trapped inside proprietary databases.

A Concrete Example: The Weekly Status Report

Instead of manually maintaining a project dashboard, keep one Markdown project file that includes:

• Scope

• Tasks

• Decisions

• A running log of updates

At the end of the week, upload that file to an AI and ask:

• What changed this week?

• What are the top 3 risks?

• What tasks are blocked and why?

• What decisions were made?

• What should next week’s priorities be?

If the AI cannot answer, that is not a failure. It is a diagnostic.

The First Steps

1. Create one Microsoft Word file for your next project with headings for Scope, Tasks, Decisions, and Log.

2. Upload it to an AI and ask it to behave like a project manager.

3. Each time the AI cannot answer a question, update the file so the information exists next time.

Final Thought

Stop optimizing applications. Start optimizing for data.

Files first. Single self contained MS Word (or Markdown if you are feeling brave) file for each project, task, notes, scope etc..

AI on top.

“Talk” to your notes by dropping them in your authorized AI tool.

The winners will not have better prompts. They will have better data.

NOTE: This is a shorter version of my original text which can be found here, Listen to a summarized version here

Overview: AI feels underwhelming because your work is trapped across too many disconnected tools. The next wave of value comes when AI can operate directly on structured work data.

TLDR: AI feels underwhelming because your work is trapped across too many disconnected tools. The next wave of value comes when AI can operate directly on structured work data. The FILE framework solves this by keeping your work in durable plain-text files (Foundation), using models on top (Intelligence), automating workflows (Logic), and interacting through interchangeable apps (Experience). Start with one Markdown project file, then use AI to generate priorities, risks, and weekly status updates.

Overview

If AI is truly as “magical” as they say, why haven’t your own efforts to use it been impressive? Why can’t you seem to see the value everyone else is talking about? Why does it feel like more fuss than it is worth?

Let’s be honest: this is a typical week for most people whose job happens on a laptop. Emails. Meetings. Spreadsheets. Logins. Status updates. Repeated follow-ups.

So the real question is simple.

How can AI help us right now, using what we already have access to today, within the confines of organizational security protocols?

This post is longer than normal. I originally dictated my thoughts into Microsoft Word and used AI to help structure them. Over the last six months, I have been focused on understanding the real impact AI will have on the knowledge worker. Not the monthly model breakthroughs or the next flashy tool, but the deeper shift in how we as humans need to change the way we think and work.

Below, I will introduce the FILE framework.

Claude recently published a workflow called CoWork, designed to help programmers collaborate with AI more systematically. The same approach translates well to knowledge work.

I am building this framework for people who work inside real enterprise constraints. Our tools are often a year or two behind what is technically possible, and we still have to operate inside strict security and compliance boundaries. The goal is maximum AI leverage without breaking governance.

Cowork: Claude Code Power for Knowledge Work | Claude

The framework is simple, but it scales.

The 36-Month Frontier: Mapping the Edge of the Possible

In roughly 36 months, we went from AI being a niche tool used mostly by programmers to AI being available to anyone with an internet connection. The pace is not linear. It is compressing.

To understand where the puck is going, we need to see how the frontier has expanded across five overlapping stages.

1) Chat Bots

This is the entry level: ask a question, get an answer, copy and paste.

This stage is often split into two groups: those who pay for a license and those who do not. The capability gap between free models and paid frontier models is often the first major hurdle in understanding why AI feels transformative for some users and underwhelming for others.

2) Contextual Uploads

This is the stage where users realize AI needs background to be useful.

Here, users develop custom prompts, upload specific files, or provide recurring context for repetitive tasks. This is where AI starts to move beyond one-off questions and into actual work.

3) Knowledge Base

Instead of uploading the same files repeatedly, you give the AI a foundational understanding of your work and your priorities.

This is still a chat-based system, but it becomes significantly more powerful. The AI starts to behave less like a search engine and more like a collaborator.

4) Autonomous Agents

This stage represents a shift toward independent operation. It splits into two paths.

Individual Agents: People build specialized assistants with custom instructions and knowledge bases for specific tasks. Tools like ChatGPT, Gemini, and Claude now make this accessible without coding.

Multi-Agent Teams: Multiple agents coordinate to accomplish a goal with minimal human involvement. For example: one agent processes data, another drafts a report, and a third audits the output for errors.

5) AI-First Workflows

This is the current edge of the frontier, and the focus of this post.

AI-first workflows require the AI to interact directly with your systems, your files, and your work artifacts. This is where AI becomes operational instead of conversational.

This is also where most organizations are not ready.

The Real Problem: Fragmented Work

If you had to surface your highest-priority task or identify a critical project bottleneck right now, could you find the answer in seconds?

Or is your work buried behind a login button across a fragmented stack of Outlook, Planner, To Do, Project, Excel spreadsheets, and SharePoint folders?

The modern knowledge worker is not failing because they are lazy.

They are failing because their work is fragmented across too many systems that do not talk to each other.

A Better Mindset: Treat AI Like a System, Not a Toy

AI is extremely capable at summarizing, organizing, and transforming information. It is also unreliable in predictable ways.

Many people treat AI errors as proof that the tools are useless. That is the wrong lesson. The better lesson is this:

When AI output is wrong, the cause is usually one of three things.

1. Missing context

2. Unclear instructions

3. A model limitation

The fix is not blind trust, and it is not rejection. The fix is to treat AI output like a draft and audit it.

This is also why a single, evolving file of personal instructions becomes powerful. Every time you clarify something to the AI, you should add that clarification to your master instruction list.

Over time, you stop prompting from scratch. You build a stable operating system for how the AI should support you.

Redefining the Knowledge Worker as a Manager of Systems

A knowledge worker is anyone whose primary value comes from judgment, synthesis, and prioritization rather than repetitive execution.

Whether you are an analyst, a researcher, or an administrator, your effectiveness depends on your ability to manage three core domains.

1. Your knowledge

2. Your time

3. Your projects

The historical model of productivity assumed that specialized apps would save us time.

Instead, we have moved toward a model of fragmented attention.

In the AI era, relying on manual dashboards and reminders scattered across separate apps is too slow.

Individuals who combine domain expertise with AI-augmented management will see their leverage multiplied.

Those dependent on manual lists and scattered notes will experience a growing lag between intention and execution.

Skating to the Puck

The most common strategic error is reacting to what AI can do today, like writing an email, rather than positioning for where it is headed.

The puck is moving toward autonomous operators.

These are systems that work directly on raw data to manage schedules, tasks, and project health.

If your project history is locked in a database that requires a login, you have effectively blinded the AI agents of tomorrow.

To build an AI-ready productivity system, we use the FILE framework.

This ensures your system remains durable even as specific AI tools and models change.

The FILE Framework

F: Foundation (The Filesystem)

This is your local directory.

It consists of folders containing plain-text Markdown (.md) files for notes, tasks, and logs.

This layer is stable, vendor-independent, and fully owned by you.

Your to-do list is a file, not an entry in a proprietary database.

I: Intelligence (The Models)

This is the AI layer.

These are the language models that reason over your foundation. Today it might be GPT-4o or Claude. Tomorrow it will be something else.

Because your data is stored as plain text, you can swap models without rebuilding your entire workflow.

L: Logic (The Orchestration)

This is where automation lives.

This layer determines how a weekly status report is generated from your daily logs, how tasks are extracted, and how project risk is flagged.

It replaces manual tracking with repeatable processes.

E: Experience (The Interface)

This is how you interact with your system.

You might use Obsidian, VS Code, or a mobile text editor. These are lenses. They are interchangeable and do not own your information.

Why Markdown Is a Practical Interoperability Layer

Markdown (.md) is a simple plain-text format.

Just as Microsoft Word uses “Heading 1,” Markdown uses #.

Because it is lightweight and structured, an AI can scan large volumes of Markdown files quickly and reliably.

Markdown wins because it is a Goldilocks format.

It is readable for humans and easy for machines to parse.

It also provides three advantages that most proprietary tools do not.

1) Zero dependency

No accounts, no licenses, and no vendor lock-in.

Even if every productivity platform you use disappears, your project history still exists as files you can open anywhere.

2) Version control

You can track how a project’s scope changed over time.

You can see when decisions were made.

You can reconstruct the evolution of your work.

3) AI-native readability

Markdown is one of the easiest formats for modern language models to reliably parse and transform.

A model can read a Markdown task list and immediately convert it into a structured plan, a schedule, or a draft status report.

When you use proprietary systems, you add friction between your work and the AI.

When you use Markdown, you reduce that friction.

Enterprise Reality: This Complements, Not Replaces, Official Systems

One important clarification.

This is not an argument to abandon organizational systems of record.

Tools like Planner, Project, Outlook, and ticketing systems exist for real reasons: collaboration, permissions, audit trails, retention policies, and continuity.

The FILE framework is a personal layer.

It is the system you control.

It is the bridge between your work and your AI tools.

The goal is not to replace official systems. The goal is to ensure your personal operating system is durable, portable, and AI-ready.

Implementation: Personal Strategic Advantage

Over time, organizations will likely shift toward more open and accessible data structures that AI can operate on.

Markdown files appear basic, but the applications that use them can be powerful. Obsidian, VS Code, and similar tools can support everything from Kanban boards to knowledge graphs.

The real advantage is not the app.

The advantage is that your data is portable.

A Concrete Example: The Weekly Status Report

Here is what an AI-first workflow actually looks like.

You maintain a project file that includes:

• Scope

• Tasks

• Decisions

• A running log of updates

At the end of the week, you give the AI the file and ask:

• What changed this week?

• What are the top 3 risks?

• What tasks are blocked and why?

• What decisions were made?

• What should the next week’s priorities be?

If the AI cannot answer those questions, that is not a failure.

That is a diagnostic.

It tells you what your system is not capturing yet.

The First Steps

If this is new to you, here is what I suggest.

1) Create a master file for your next project

For your next project, create a single Markdown file with headings for:

• Scope

• Tasks

• Decisions

• Log

Think of the log like a save point in a video game.

2) Upload it to an AI

Give this file to an AI tool you already have access to.

Ask it to behave like a project manager.

If it cannot answer, add a new section to your file so that the information exists next time.

3) Bridge the gap

If your data is trapped in systems like GitHub, Planner, or SharePoint, export what you can and paste it into your file.

Do not do this forever.

Do it as an experiment.

See what questions the AI helps you answer, and identify what information is missing.

Final Thought

Stop optimizing applications.

Start optimizing for data.

Files first. Markdown everywhere. AI on top.

By adopting plain text as your primary substrate, you create the conditions required for AI systems to operate at scale.

The winners will not have better prompts. They will have better data.

The real question is whether we will keep building digital silos, or whether we will commit to building a readable foundation for our work.

TL;DR: To move beyond static reports and manual spreadsheets, universities must treat analytics as a software engineering discipline. This requires a unified pipeline where data is ingested, modeled, versioned in GitHub, and deployed securely.

A modern university analytics ecosystem integrates data from core operational platforms into a single, scalable workflow. It transforms raw, siloed information into reliable strategic insights that leadership can trust.

The Challenge: Unifying the University

Universities depend on several major data domains to support analytics, compliance, and strategic planning. Bringing these traditionally gated systems into a single “source of truth” is the primary challenge of higher ed analytics.

The raw inputs for this lifecycle come from the following data domains. Each with its own security, culture, documentation, and last but not least, political landscape:

• Student Information Systems (Enrollment, retention)

• HR and Workforce (Faculty effort, staffing)

• Sponsored Research (Grants, eRA activity)

• Finance (General ledger, accounting)

• Infrastructure (Space utilization)

• Faculty Activity (Publications, awards)

The Solution: A Unified Lifecycle

To turn these siloed sources into insight, we need a structured lifecycle. Here is an example framework.

The Ingestion Pipeline (The Intake)

All institutional dataflow starts here. Whether using Microsoft Fabric Dataflows, Tableau Prep, or custom ETL tools, the goal is identical: extraction, transformation, and normalization.

• The Goal: Move from “manual exports” to repeatable, automated pipelines.

• The Result: A clean, standardized foundation where the data is trusted before it ever reaches a report.

The Data Model (The Brain)

Once data is ingested, it must be shaped. In this layer, often a Microsoft semantic model or Tableau logical layer, we merge systems and define rules and calculations. This is where we establish cross‑system relationships, standardize definitions, and ensure consistency across domains.

We build measures, calculated columns, parameters, date tables, and time‑intelligence functions. In Power BI, the data model combined with DAX (Data Analysis Expressions) is a powerful expression language. Instead of looping through rows or merging datasets like in R, Python, or SAS, DAX creates calculated measures that operate across related tables without physically merging data.

• Why it matters: This ensures that “Research Expenditure” means the exact same thing in the College of Engineering as it does in the Provost’s office.

GitHub and Code Management (The Governance)

This is the differentiator between a “spreadsheet culture” and an “engineering culture.” Even though tools like Power BI are low-code, the logic governing them should be treated like software. We use GitHub to separate the logic (report definitions, transformations) from the data (student records, financials, sponsored research, HR data etc.).

GitHub allows us to:

• Version Control: Roll back to previous versions if a metric breaks.

• Collaborate: Use branching and pull requests to manage changes safely.

• Secure: Keep logic public/shared while keeping sensitive university data locked down.

For a deeper dive on how to use GitHub to manage projects (without writing code), read Part 1 of my series here.

The Deployment Pipeline (The Release)

We never want to push changes directly to the production set of dashboards. Instead, we use a structured pipeline:

• Development: Where we build and experiment.

• Test: Where we validate accuracy with stakeholders.

• Production: The live environment for decision-makers.

This ensures rigorous quality assurance and predictable updates.

Balancing Central vs. Local: The Unit-Level Ecosystem

A campus-wide system is powerful, but it can be slow. A major operational unit such as Research, Finance, or a large College needs to move faster.

We need both campus level and Unit-Level Analytics Environments to be truly agile. Just as colleges and operational units have unique strategic plans and priorities, they also need specialized versions of the main lifecycle that allow specific teams to:

• Iterate Quickly: Respond to operational needs in real-time.

• Specialize: Build models aligned with deep domain expertise (e.g., bibliometrics for Research).

• Experiment: Try new things without waiting for a campus-wide release.

This structure allows the university to have a “central truth” while empowering units to have “local agility.”

The Output: Decision-Ready Analytics

Ultimately, the technology serves the user. The production models feed downstream tools like Power BI, SharePoint, and Teams. This is where the work pays off, enabling:

• Operational reporting for managers.

• Executive dashboards for Deans and VPs.

• Scenario modeling (”What if we increase grant targets by 10%?”).

• Research collaboration insights.

To see how we implement these models technically, read my article on Elevating Strategic Metrics with Power BI and Cloud Integration.

Conclusion

This is more than a technical workflow; it is a strategic analytic framework. A modern analytics ecosystem only becomes valuable when its insights reach the people who make decisions. To get there, institutions must invest in a coordinated strategy to export, centralize, and unify data from traditionally siloed systems.

By adopting this framework, universities create a scalable, trusted foundation that empowers leadership to make decisions based on a single, consistent truth.

TLDR; GitHub gives higher ed project teams a unified system to organize work, track decisions, and manage progress without drowning in email chains. Repositories centralize information, issues expose real work and accountability, projects provide real time oversight, and agile workflows match the messy, shifting reality of complex initiatives. This isn’t about coding. It’s about running projects with discipline.

Overview

Higher ed work breaks down because communication is scattered, ownership is unclear, and decisions disappear into inboxes. GitHub fixes these problems by providing structure, transparency, and a single operational source of truth.

This walkthrough uses a public Microsoft repository to demonstrate how GitHub actually works. The focus is project management fundamentals: defining work, tracking progress, and coordinating teams through issues, comments, and project boards.

Microsoft at Scale: A Practical Example

Microsoft operates at massive scale: 7,400 public GitHub repositories, 4,500+ contributors, and thousands of active tasks.

We’ll examine PowerToys as a concrete example. The software itself doesn’t matter. The workflow does.

I personally use PowerToys dozens of times a day and have done for years. It gives Windows users a Mac like experience via a central command bar which has dozens of advanced features you can run directly in whatever application you are in.

Click here for a video introduction.

QuickStart: Core Concepts

You only need three concepts to understand GitHub as a project management system.

The Repository: The Workspace
One container for everything: plans, diagrams, notes, decisions, drafts, and deliverables. No version chaos. No “who has the latest.”

Issues: The Work
Tasks, questions, bugs, data pulls, decisions, and requests, captured as discrete issues. They force clarity on ownership and eliminate hidden work.

Projects: The Workflow
Kanban-style boards that show work moving across stages. This transforms GitHub from a document bucket into a real project management platform.

Microsoft’s 7,400 repositories mirror the kinds of parallel initiatives universities run but with far more discipline and visibility.

PowerToys snapshot:

• 586 contributors
• 7,582 open issues
• 29,100 closed issues

This is project management at scale, not meetings, not email chains.

Issues in Detail

Issues prevent context loss. Every discussion, decision, blocker, and subtask stays within the issue, not buried in someone’s inbox.

https://github.com/microsoft/PowerToys/issues/43864

Issue 43864 (“PowerToys Run doesn’t find files”) shows it clearly:

• Unique ID
• Full history
• Comments anchored to the work
• Clear status
• Traceability end to end

This is what higher ed has been missing.

Scroll to see the initial report, comments, sub-issues, links, and status changes.

On the right panel you see attributes: labels, assignees, linked pull requests, and related projects.

Projects

Projects give you a way to view issues from one or multiple repositories in a structured format. This is crucial for leaders supervising multiple initiatives. It prevents drowning in thousands of issues while still surfacing the ones that matter.

Leadership or Project Manager View: Project status across all relevant initiatives. What’s been completed, what remains, current roadblocks, decisions made, upcoming steps, and clear ownership of who is doing what.

Data Analytics or Team Lead View: What the team is working on, individual workload, where approvals or decisions are needed, and the full discussion history behind each decision or change. This makes reviews faster and exposes blockers early.

Open this example:
https://github.com/orgs/microsoft/projects/1711/

You cannot break anything. Explore the tabs and views.

Project Management

GitHub is powerful only when paired with the right project management mindset.

Higher ed defaults to waterfall: long planning cycles, committees, consensus documents, and kickoff ceremonies. It feels productive but collapses the moment reality changes.

Most analytics and cross-unit initiatives shift constantly.

Exploratory Analytics Requires Adaptive Workflow Strategies

When the destination shifts, the plan must too. Research questions evolve. Requirements change. Stakeholders refine expectations. Data realities surface mid-project. This is normal, not a sign of project failure.

Examples of Evolving Questions

• How will federal rate changes shape future research funding?
• How should institutions measure research output fairly?
• How does teaching load influence scholarly productivity?
• What happens when exploratory analysis reveals new questions?

Work changes because understanding changes.

Why Waterfall Project Management Breaks Down

These shifts are normal. Requirements change. Stakeholders refine questions. Data realities emerge unexpectedly.

Waterfall assumes stability, fixed requirements, and clarity upfront. It collapses when the environment changes.

Why Agile Fits Analytics Work

Agile embraces uncertainty. It breaks work into small increments, introduces continuous feedback, and adjusts direction as understanding deepens.

GitHub aligns naturally with agile principles. Issues are increments. Projects visualize flow. Leaders get clarity, momentum, and real time visibility instead of ceremonial updates.

Agile Project Management

Agile replaces months of planning with rapid cycles of working, reviewing, and adjusting.

In an agile model:

• Work is broken into small, manageable chunks.
• Priorities shift as new information emerges.
• Frequent review and correction.
• Early work is visible to stakeholders instead of hidden until the end.

This matches the evolving nature of higher ed analytics and cross-unit project work.

Conclusion

GitHub delivers the project management discipline higher ed has never had: transparent workflows, accountable task tracking, shared context, and real time visibility. It ends email-driven chaos and replaces it with a system built for complex, evolving work.

Next we will explore version control, security, organizations, and connecting GitHub to your local machine.