ORS demo readiness

Report date: 2026-06-01
Audience: Office for Research Services (ORS) and internal innovation stakeholders
Pipeline snapshot: full-refresh-report.md (generated by python3 scripts/refresh_all.py)

1. What the resource map currently contains

The DePaul Hardware Technology Resource Map is a structured, evidence-backed inventory of DePaul facilities, programs, equipment, curriculum, and the people and projects that connect to them. It is maintained as YAML registries plus generated MkDocs pages (docs/), not as a live operational database.

Core idea: Document who uses what, with what evidence, so research administration, colleges, and innovation units can see cross-unit hard-tech capacity without treating affiliation or co-authorship as proof of shared facility use.

Layers in the prototype:

Layer	Registry	Role
Resources	`resources/*/.md`, `data/resource_*.yaml`	Facilities, labs, centers, partners, courses
People	`data/people.yaml`, `data/person_resource_links.yaml`	Named directors, PIs, faculty, staff with cited roles
Grants	`data/grants.yaml`, person/grant/resource link YAML	Seed awards (internal CSV + documented external programs)
Publications	`data/publications.yaml`	Peer-reviewed scholarly outputs (conservative resource links)
Outputs	`data/outputs.yaml`	Non-publication artifacts (productions, games, installations, civic tech)
Equipment	`data/resource_equipment.yaml`, `equipment-index.md`	Category-tagged equipment lists per resource
Graph exports	`data/graph_exports/*.csv`	Node/edge tables for inspection (Neo4j import not started)

Public site today: ownership-unit indexes, resource detail pages, equipment catalog, curriculum index, and selected operational reports. There are no public MkDocs tabs for People, Grants, Publications, or Outputs as browsable directories.

2. Current entity counts

Counts from the latest full-refresh-report.md:

Entity	Count
Resources (total)	265
Resources (non-course)	78
*Curriculum / course resources (`CUR-`)**	187
People	115
Grants	33
Publications	34
Outputs	18
Equipment resource records (resources with ≥1 equipment block in YAML)	51
Equipment line items (individual named items)	345

Non-course resources by prefix (home stats): CDM 22, CSH 19, UNI 14, EXT 11, ART 5, MUS 4, TTS 3 (78 facility/program/partner/service nodes).

3. Current edge counts

Edge type	Total	`include_in_graph=true`	Excluded from graph
person–resource	209	174	35
person–grant	33	33	0
grant–resource	12	8	4
person–publication	39	38	1
publication–resource	6	4	2
person–output	15	14	1
output–resource	12	12	0
course–resource (documented, explicit only)	2	—	—
facility–facility (documented)	1	—	—

Evidence levels (all edge kinds, export time): direct 187 · affiliation 59 · topical 8 · administrative 1 · excluded 42 · needs_review 2.

Resource–equipment: Equipment is modeled as structured lists on each resource in data/resource_equipment.yaml and rendered on resource pages / equipment-index.md. It is not exported as a separate resource–equipment graph edge type in data/graph_exports/ today.

4. What the prototype already demonstrates

Cross-unit resource inventory — 78 non-course nodes with access status, verification, equipment categories, and documented relationships.
Named stewardship — 115 people with role types (director, faculty_lead, grant_pi, etc.) and evidence URLs or repo citations.
Conservative graph discipline — include_in_graph flags, evidence levels, and intake rules that reject affiliation-only facility claims (publication-intake-rules.md, output-intake-rules.md).
Grants as first-class records — 33 seed grants with PI links; 8 graph-included grant–resource edges where facilities text is explicit (grants-layer-review.md).
Evidence objects beyond grants — 34 publications and 18 outputs linking people to scholarly or practice-based work, with sparse high-confidence resource edges (4 publication–resource, 12 output–resource).
Equipment layer — 345 line items across 51 resources for “what instruments exist where.”
Curriculum bridge — 187 hardware-related courses; 2 explicit course↔facility links (catalog- or news-backed only).
Operational QA — automated refresh report, hub-resource warnings, orphan checks, and layer-specific reviews (graph-readiness-review.md, publications-quality-review.md, outputs-quality-review.md).
Display policy — data/site_display.yaml can hide grant PIs and sensitive contacts on public builds while retaining internal graph records.

5. What it intentionally does not claim

A complete list of every DePaul lab, studio, or instrument.
That every grant PI uses a specific facility (25 grant_pi links to UNI-001 are provenance-only and excluded from the graph).
That co-authorship, co-production, or center membership implies collaboration or shared resource use.
That topical similarity (same research area) proves instrumentation or space use.
Real-time accuracy — counts reflect last refresh and public-source verification dates.
Production Neo4j or enterprise search — CSV exports are for inspection and pilot import only.
Legal or MOU completeness for external partners beyond publicly documented text.

6. Known limitations of public-source discovery

Limitation	Effect
Official pages omit facility names	Person–publication or person–output links without resource edges (by design).
Generic contacts only	CDM-002, CSH-008 have equipment data but no named person–resource graph edges.
Truncated grant abstracts	Internal URC/QIC CSV harvest lacks amounts, end dates, and facilities narratives.
Theatre / music practice outputs	Batch 2 found program pages but few named productions or studio releases with facility text.
Theatre season URLs unstable	Production playbills not reliably fetchable in discovery passes.
Pre-DePaul work	Retained in registry sometimes but not used to infer current DePaul resources.
URL-only evidence	~76% of person–resource `evidence_file` values are HTTP URLs, not local repo paths (graph-readiness-review.md §8).
Manual review bandwidth	Quality passes downgrade edges (e.g., POL-008 Wagner → Plant digital twin) rather than delete records.

7. Why ORS data would substantially improve the graph

ORS systems hold authoritative proposal and award metadata that public web pages rarely expose in structured form:

Who applied and who was funded (PI, co-PI, unit) on every internal and sponsored project.
What facilities, cores, and equipment were proposed in narrative sections.
When projects start and end, and how much was awarded.
Which proposals are unfunded vs active vs closed — enabling time-aware maps.

Today, 25 internal grants share ORS administration on UNI-001 as grant_pi activity without lab mapping. ORS exports could replace inference with proposal-ID–keyed grant–resource and person–grant edges grounded in facilities text.

Purchasing data would close the loop from award → acquisition → asset location, especially for equipment grants and core instruments.

8. Most useful data fields from ORS

Priority	Field	Use
High	Proposal / award ID	Stable keys for merge and refresh
High	PI, co-PIs, investigators	Person–grant edges without CSV-only PI
High	Unit / college / department	Cross-unit views, orphan checks
High	Funder, program, internal/external	Grant typing and filters
High	Status (proposal / award)	Active vs historical graph
High	Start / end dates	Timeline and stale-edge review
High	Facilities / resources / equipment narrative (exact text)	Grant–resource and publication/output validation
Medium	Amount (or range bucket)	Portfolio views; aggregate for public display
Medium	Abstract (full, permissioned)	Discovery seeding; not for public verbatim dump
Medium	Keywords	Search and clustering
Medium	Community partners / collaborators	EXT and UNI partner linkage
Medium	`public_display` / permission flag	Governance (see §10)

Full field list: internal-data-wishlist.md § A–B.

9. Most useful data fields from purchasing

Priority	Field	Use
High	Item description + category	Equipment taxonomy enrichment
High	Purchase date	Lifecycle and “active” resource signals
High	PI / responsible person + account / project	Person–resource and grant–resource validation
High	Funding source or grant ID	Tie acquisitions to GRA-* records
Medium	Vendor	Maintenance and support clustering
Medium	Building / room	Location fields on resources
Medium	Asset tag (if shareable)	Dedup with existing equipment lines
Medium	Cost or cost band	Internal analytics; aggregate publicly
High	`public_display_allowed`	Privacy gate

Full field list: internal-data-wishlist.md § C.

10. Privacy / sensitivity considerations

Separate internal graph use from public display — Records may be include_in_graph: true but include_in_public_site: false (grant PIs today).
Do not publish full proposal narratives, budgets, or unreleased outcomes without ORS approval.
Aggregate dollar amounts on public views when exact figures are sensitive.
Protect unfunded proposals and pending awards unless explicitly cleared.
Mark each edge with evidence_source (ORS export, purchasing, public web) and permission_level.
Avoid exposing student names from proposals unless policy allows.
External partners — distinguish DePaul-owned resources from EXT nodes; do not imply MOUs where none are documented.

Current defaults: people_contacts.include_grant_pis: false in data/site_display.yaml.

11. Suggested next collaboration with ORS

Pilot export — One recent award cycle (e.g., URC/QIC + selected sponsored awards) with fields in internal-data-wishlist.md § A, plus facilities-text excerpts § B.
Governance workshop — Agree public_display levels and which proposal statuses may enter the graph at all.
Joint review — ORS staff validate 10–15 grant–resource edges against proposal PDFs; refine intake rules.
Purchasing slice — Equipment purchases tied to 3–5 known PI accounts for CDM/CSH cores.
Refresh integration — Scripted import idempotent on proposal ID; regenerate full-refresh-report.md after each drop.
Demo follow-up — Use ors-demo-script.md for live walkthrough; share ors-demo-one-page-summary.md pre-read.

Regenerate counts: python3 scripts/refresh_all.py