DePaul Resource Map

← All packets

2026-06-14-ors-annual-reports-2020-2025

Location: sources/inbox/2026-06-14-ors-annual-reports-2020-2025/

Submission

Title
ORS Annual Reports 2020 - 2025
Submitter
Eric Landahl (elandahl@depaul.edu)
Unit
Physics
Submitted
2026-06-14
Description
—

Source

Type
annual_report
Origin
DePaul public
Source date
—
URL
—
Visibility
public
Storage permission
yes
Sensitivity
—

Workflow

Intake status
submitted
Review status
refactor_proposed
Refactor status
proposed
Priority
normal
Created at
2026-06-14T03:46:33.219891+00:00
Git branch
development

Uploaded files

Cursor refactor prompt

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

# Cursor Refactor Prompt — 2026-06-14-ors-annual-reports-2020-2025

> 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.
>
> Prompt refreshed 2026-06-14 from template (documentation only).
> See `docs/source-packet-workflow.md` (hypertext, reciprocity, and output rules).

---

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

Source packet: sources/inbox/2026-06-14-ors-annual-reports-2020-2025/

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-06-14-ors-annual-reports-2020-2025/metadata.yaml (or intake.yaml if present)
- sources/inbox/2026-06-14-ors-annual-reports-2020-2025/submitter_notes.md (or curator_notes.md)
- sources/inbox/2026-06-14-ors-annual-reports-2020-2025/review_notes.md
- sources/inbox/2026-06-14-ors-annual-reports-2020-2025/evidence_checklist.md
- every file under sources/inbox/2026-06-14-ors-annual-reports-2020-2025/uploads/
- docs/source-packet-workflow.md
- docs/source-evaluation-policy.md
- docs/reports/grant-ingestion-governance.md
- docs/main-evidence-verification-audit.md
- resource-map-index.md (ID governance and field standard)


Task:
- Review this source packet and inspect the current Resource Map repository.
- Propose evidence-backed updates to the EXISTING corpus that reflect supported
  claims in evidence_checklist.md. Suggested targets: (resolve from packet).
- 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.

GRANT AND AWARD INGESTION (this packet):
- Follow docs/reports/grant-ingestion-governance.md.
- Unresolved knowledge is still knowledge: add evidence-backed awards to
  data/grants.yaml even when PI is not in people.yaml (person_name only, no person_id).
- Separate: grant existence | PI identity (resolved/unresolved/ambiguous) |
  resource links (resolved/unresolved/not_supported).
- person_grant_links.yaml only when person_id is resolved.
- grant_resource_links.yaml only when facility naming is explicit and resolved.
- Do NOT discard ORS listing rows solely because PI is absent from people.yaml.
- Index unresolved rows in packet extracted/; report resolved vs unresolved counts.

--------------------------------------------------
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.

--------------------------------------------------
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 capture_status for URL snapshots)
   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
G. Relationships considered but rejected
H. Evidence supporting every accepted relationship
I. Any provenance concerns
J. Any conflicts with existing repository content

--------------------------------------------------
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.