`2026-08-19-annual-report-2026`

Location: sources/inbox/2026-08-19-annual-report-2026/

Submission

Title: Annual Report 2026
Submitter: Lauren Miller (lmille74@depaul.edu)
Unit: ORS
Submitted: 2026-08-19
Description: —

Source

Type: annual_report
Origin: ORS
Source date: 2026-08-19
URL: https://offices.depaul.edu/research-services/about/Documents/ORS%20Annual%20Report%202026.pdf
Visibility: internal
Storage permission: yes
Sensitivity: Try accessing the weblink first. I'm curious since that is behind a password protected site, if it will work

URL capture

Submitted URL: https://offices.depaul.edu/research-services/about/Documents/ORS%20Annual%20Report%202026.pdf
Final URL: https://offices.depaul.edu/research-services/about/Documents/ORS%20Annual%20Report%202026.pdf
HTTP status: 200
Capture status: success
Retrieved: 2026-08-19T21:02:00.185896+00:00
Content type: application/pdf
Snapshot: source_snapshot/page.pdf
SHA-256: 2857e7739e572038…

Workflow

Intake status: accepted
Review status: reviewed
Refactor status: promotion_discovery_complete
Priority: high
Created at: 2026-08-19T21:02:00.182614+00:00
Git branch: main

Uploaded files

uploads/ORS_Annual_Report_2026.pdf (1442347 bytes)

URL snapshots

source_snapshot/page.pdf (1442347 bytes)

Candidate links (human review only)

— extracted link(s). Not sources — do not auto-ingest.

# Candidate Links (human review only)

> Hyperlinks extracted from the submitted URL snapshot.
> **Not sources.** Do not auto-ingest, fetch, or refactor from these links.
> A curator reviews this list and manually adds selected URLs as separate sources.

- **Submitted URL:** https://offices.depaul.edu/research-services/about/Documents/ORS%20Annual%20Report%202026.pdf
- **Snapshot file:** `source_snapshot/page.pdf`

## Extracted links

_No links extracted (empty page, non-HTML snapshot, or fetch failed)._

## Curator selection

_Mark links to intake separately (new submission or added upload). Do not assume
candidate links are evidence until captured and reviewed._

- [ ] Selected for follow-up intake:
- [ ] Rejected (not relevant):

Cursor refactor prompt

Copy this into Cursor on development when the packet is reviewed.

# Cursor Refactor Prompt — 2026-08-19-annual-report-2026

> Copy the block below into Cursor on the `development` branch once this packet
> has been reviewed. It drives an evidence-backed refactor of the existing
> Resource Map corpus. This prompt does NOT run extraction or scraping — Cursor
> reads the repository context and proposes diffs for human review.
>
> See also: `docs/source-packet-workflow.md` and `docs/source-evaluation-policy.md`
> (hypertext, reciprocity, source evaluation, and output rules).

---

```
You are refactoring the DePaul ORS Resource Map corpus on the `development` branch.

Source packet: sources/inbox/2026-08-19-annual-report-2026/

You are a repository editor, not a chatbot. The objective is evidence-backed
repository refactoring — not extraction, scraping, or chatty summarization.

Before editing, read:
- sources/inbox/2026-08-19-annual-report-2026/metadata.yaml (or intake.yaml if present)
- sources/inbox/2026-08-19-annual-report-2026/submitter_notes.md (or curator_notes.md)
- sources/inbox/2026-08-19-annual-report-2026/review_notes.md
- sources/inbox/2026-08-19-annual-report-2026/evidence_checklist.md
- every file under sources/inbox/2026-08-19-annual-report-2026/uploads/
- sources/inbox/2026-08-19-annual-report-2026/candidate_links.md (review only — not sources)
- sources/inbox/2026-08-19-annual-report-2026/source_snapshot/ (if URL snapshot saved)
- docs/source-packet-workflow.md
- docs/source-evaluation-policy.md
- docs/reports/repository-wide-refactor-governance.md
- docs/main-evidence-verification-audit.md
- resource-map-index.md (ID governance and field standard)

URL SOURCE (this packet):
- Submitted source URL: https://offices.depaul.edu/research-services/about/Documents/ORS%20Annual%20Report%202026.pdf
- Saved snapshot: sources/inbox/2026-08-19-annual-report-2026/source_snapshot/page.pdf
- HTTP status: 200; retrieved: 2026-08-19T21:02:00.185896+00:00
- Read candidate_links.md — hyperlinks extracted for HUMAN REVIEW ONLY.
- Do NOT fetch, follow, auto-ingest, or treat candidate links as evidence.
- Use ONLY saved source material in this packet (uploads/, source_snapshot/)
unless a human curator adds selected links as separate captured sources.

REPOSITORY-WIDE REFACTOR (required — intake type is NOT refactor scope):
- Read docs/reports/repository-wide-refactor-governance.md before editing.
- Every source packet may update ANY knowledge layer: people, facilities, equipment,
laboratories, centers, institutes, programs, courses, grants, publications,
outputs, external partners, expertise, capabilities, relationships, hyperlinks,
reciprocity, and evidence quality.
- Never treat this packet as grant-only, people-only, publication-only, facility-only,
or equipment-only because of intake channel or source_type metadata.
- Classify EVERY discovery: (1) evidence-backed repository update,
(2) candidate knowledge — preserve with provenance and snippet,
(3) rejected claim — evidence does not support it.
- Candidate preservation: do NOT silently discard facility, equipment, laboratory,
center, capability, or relationship signals. Record in section M and/or
extracted/candidates.yaml when evidence is insufficient for promotion.
- When the source documents grants/awards, ALSO apply grant-ingestion-governance.md
for grant-layer writes — that policy does not limit other layers.

PROMOTION DISCOVERY RULE (mandatory — candidate preservation is the BEGINNING, not the end):
- For EVERY candidate produced (facility, lab, center, institute, clinic, equipment
collection, capability, external facility, program, course, partner, person, relationship):
1. Preserve the candidate with full provenance.
2. Perform targeted evidence discovery using high-confidence sources permitted by
docs/source-evaluation-policy.md: institutional websites, faculty profiles,
laboratory/center/facility pages, project pages, department pages, grant-related
pages, ORCID, Google Scholar, ResearchGate, Web of Science, Scopus, DOI-linked
publications, and official partner websites.
3. Capture all newly discovered evidence as sources with provenance (a packet capture
— never an unsourced claim).
4. Re-evaluate every candidate after discovery.
5. Promote candidates that meet promotion criteria (institutional/project evidence —
the bar is unchanged; targeted discovery raises the obligation to look, not lowers it).
6. Create/update all required entities and all evidence-backed typed relationships.
7. Evaluate and add reciprocal hyperlinks and relationship visibility.
8. Preserve unresolved candidates with reason_not_promoted.
9. Record section N: sources reviewed, sources imported, candidates promoted,
candidates deferred, relationships added, reciprocal links added, remaining gaps.
- A source is NOT fully processed until promotion review is completed, OR explicitly
deferred with justification recorded in section N.

SOURCE EVALUATION AND EVIDENCE POLICY (required):
- Read docs/source-evaluation-policy.md before proposing edits.
- Distinguish CAPTURED SOURCES (everything saved in this packet) from SOURCES
USED AS EVIDENCE (only those cited in evidence_checklist.md and the diff).
- Preserve provenance for all captures regardless of use.
- Record intake channel in metadata: intake_form (primary source from intake app)
vs curator_added (maintainer-added files/captures outside the form). List
added_by, added_at, and added_rationale for every curator-added source.
- capture_status: success | partial | failed (HTTP 403 = partial, never success).
- High-confidence sources include university profiles, lab/department sites,
grants, journal articles, DOI pages, Google Scholar, ORCID, Web of Science,
Scopus, ResearchGate (when clearly the scholar), professional society profiles,
official project sites, and faculty-maintained research websites.
- Those sources may support people, publications, collaborations, memberships,
service roles, expertise, research themes, and professional activities.
- Remain conservative for facility ownership, equipment ownership, facility access,
organizational authority, administrative responsibility, laboratory affiliation,
and operational control — require institutional or project evidence.
- Scholarly indexes (Google Scholar, ORCID, Web of Science, Scopus, ResearchGate)
are strong for publications, collaborations, and expertise; NOT sufficient alone
for facility or equipment claims.
- Lower confidence: news, press releases, blogs, marketing (corroborate first).
- Very low confidence: social media, forums, anonymous sites (not primary evidence).
- Publications: resolve and verify DOI (Crossref/ORCID); register citation + abstract in
publications.yaml; link by DOI — do not store full-text articles in packets.
- ORCID on people.yaml: verified (Crossref authorship) or probable (ORCID API);
see docs/source-evaluation-policy.md § ORCID registry — identity only, not facility claims.
- Service/editorial/society roles: do NOT add to resource pages unless tied to
facilities or hardware.

Task:
- Review this source packet and inspect the current Resource Map repository.
- Perform a FULL Resource Map impact assessment (all layers) before editing.
- Propose evidence-backed updates to the EXISTING corpus that reflect supported
claims in evidence_checklist.md. Suggested targets: (resolve from packet) —
these are hints only; assess the entire repository for impact.
- Preserve candidate knowledge (section M) for signals that cannot yet be promoted,
then run mandatory promotion review (see PROMOTION DISCOVERY RULE) and record section N.
- Strengthen the network of evidence-backed relationships — do not simply append
isolated facts. The Resource Map is a hypertext knowledge system.

Edit source-of-truth files only:
- resources/<PREFIX>/<ID>.md (prose: Description, Documented Relationships, Notes)
- data/resource_access.yaml, data/resource_verification.yaml, data/resource_equipment.yaml
- data/people.yaml (each association needs evidence_file + evidence_text)
- data/grants.yaml, data/person_grant_links.yaml, data/grant_resource_links.yaml (when evidenced)
- documented-link YAML (e.g. data/course_resource_links.yaml)

Hard guardrails (do not violate):
- Do not invent claims. Every change must trace to evidence present in this packet.
- Do not infer facilities, equipment, ownership, collaboration, or organizational
relationships unless directly evidenced (shared unit is not collaboration;
affiliation is not facility use; keyword match is not proof).
- Do not create relationships based solely on topic similarity.
- Never invent URLs, emails, dates, confidence scores, or person IDs.
- Preserve existing resource IDs; assign new IDs sequentially per resource-map-index.md.
- When evidence is incomplete, use needs_review — do not inflate confidence.
- Do not edit anything under docs/ (generated mirror). Do not run sync_docs.sh,
mkdocs, or graph exports.
- Produce a normal Git diff of proposed file edits only.
- Stop for human review before any commit. Do not commit, push, or merge.

--------------------------------------------------
HYPERTEXT AND RECIPROCITY REQUIREMENTS
--------------------------------------------------

For every proposed relationship involving people, facilities, laboratories,
equipment, grants, publications, outputs, departments, colleges, external
partners, or organizations:

1. Create human-readable hyperlinks wherever appropriate.
2. Prefer reciprocal links. If A links to B, evaluate whether B should also
link back to A.
3. Report all new links created.
4. Report all reciprocal links created.
5. Report all links deliberately NOT created and explain why.
6. Every relationship must be associated with one or more explicit sources.
7. Every relationship should preserve provenance.
8. Do not create relationships based solely on topic similarity.
9. Do not infer facilities, equipment, ownership, collaboration, or
organizational relationships unless supported by evidence.
10. If a source mentions an entity not yet in the repository: do not silently
discard it; do not invent a page; list it as a candidate addition with
supporting evidence.
11. When updating pages, prefer improving existing content over creating new content.
12. Preserve narrative readability.
13. Preserve existing evidence.
14. Strengthen evidence visibility where appropriate.
15. Prefer repository-wide consistency over local page optimization.

AUDIT-DRIVEN REFACTORS (when acting on docs/reports/*-audit.md):
- Follow docs/reports/audit-driven-refactor-policy.md.
- Prefer high-value, low-risk surfacing; audit findings alone are NOT evidence.
- Surface relationships already in YAML/registry/packets; do not invent claims to close gaps.
- Distinguish: knowledge surfacing | hyperlink improvement | reciprocal link |
provenance improvement | new discovery (source packet only).
- Report in refactor_output.md: relationships surfaced, hyperlinks added,
reciprocal links added, evidence used, recommendations NOT implemented and why.
- Incremental diffs; preserve narrative readability; stop before commit unless told.

--------------------------------------------------
REFACTOR OUTPUT REQUIREMENTS
--------------------------------------------------

Provide all of the following before or alongside the Git diff:

A. Source evaluation summary:
1. Captured sources (every file in this packet; include intake_channel
intake_form vs curator_added, capture_status for URL snapshots, and
added_by / added_at / added_rationale for curator-added sources)
2. Sources used as evidence (map each to evidence_checklist.md claims)
3. Sources reviewed but not used
4. Reason not used (for each unused capture)
B. Proposed repository changes
C. New relationships identified
D. New hyperlinks created
E. Reciprocal hyperlinks created
F. Candidate entities not yet represented (include all category-2 discoveries)
G. Relationships considered but rejected
H. Evidence supporting every accepted relationship
I. Any provenance concerns
J. Any conflicts with existing repository content
L. Full Resource Map impact assessment (per layer: reviewed, updates, candidates, rejections)
M. Candidate knowledge registry (type, label, snippet, evidence_file, reason_not_promoted)
N. Promotion review summary (REQUIRED when candidates are produced — see PROMOTION
DISCOVERY RULE): sources reviewed, sources imported, candidates promoted, candidates
deferred, relationships added, reciprocal links added, remaining evidence gaps (or
explicit deferral with justification)
K. Audit implementation summary (when acting on a repository audit):
- Audit report path
- Relationships surfaced (with evidence paths)
- Hyperlinks added
- Reciprocal links added
- Evidence used
- Recommendations intentionally not implemented and why

--------------------------------------------------
KNOWLEDGE INTEGRITY REQUIREMENTS
--------------------------------------------------

Strengthen: discoverability, provenance, hyperlink structure, reciprocal
relationships, evidence visibility, and consistency.

Avoid: hallucinated entities, unsupported relationships, speculative facility
assignments, speculative collaborations, and speculative equipment ownership.

After you finish, a human will review the Git diff against evidence_checklist.md,
then run: ./sync_docs.sh && .venv/bin/mkdocs build --strict
```

---

## After the refactor

1. A human reviews the Git diff against `evidence_checklist.md` — including sections
C–J of the refactor output (links, reciprocity, rejected relationships, candidates).
2. On approval, run `./sync_docs.sh` then `.venv/bin/mkdocs build --strict`.
3. Commit to `development`; only merge to `main` after a clean, tested build.