DePaul Resource Map

← All packets

2026-06-13-dpu-rfu-awarded-projects

Location: sources/inbox/2026-06-13-dpu-rfu-awarded-projects/

Submission

Title
—
Submitter
— (n/a)
Unit
—
Submitted
—
Description
—

Source

Type
—
Origin
—
Source date
—
URL
—
Visibility
—
Storage permission
no
Sensitivity
—

Workflow

Intake status
—
Review status
—
Refactor status
—
Priority
—
Created at
—
Git branch
—

Uploaded files

No files in uploads/.

Cursor refactor prompt

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

# Cursor Refactor Prompt — 2026-06-13-dpu-rfu-awarded-projects

> Copy the block below into Cursor on the `development` branch once this packet
> is `ready_for_refactor`. Prompt refreshed 2026-06-14 from
> `sources/inbox/_template/refactor_prompt.md` (documentation only; no refactor rerun).
>
> See `docs/source-packet-workflow.md` and `docs/source-evaluation-policy.md`.

---

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

Source packet: sources/inbox/2026-06-13-dpu-rfu-awarded-projects/

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-13-dpu-rfu-awarded-projects/intake.yaml (or metadata.yaml if from the intake app)
- sources/inbox/2026-06-13-dpu-rfu-awarded-projects/curator_notes.md (or submitter_notes.md)
- sources/inbox/2026-06-13-dpu-rfu-awarded-projects/review_notes.md
- sources/inbox/2026-06-13-dpu-rfu-awarded-projects/evidence_checklist.md
- every captured file in this packet (uploads/, source_snapshot/, source_snapshot/captured/)
- docs/source-packet-workflow.md
- docs/source-evaluation-policy.md
- docs/reports/grant-ingestion-governance.md (when packet includes grants/awards)
- docs/main-evidence-verification-audit.md
- resource-map-index.md (ID governance and field standard)
- sources/inbox/2026-06-13-dpu-rfu-awarded-projects/intake.yaml

SOURCE EVALUATION AND EVIDENCE POLICY (required):
- 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: intake_form (intake app) vs curator_added (maintainer
  additions outside the form). Every curator_added source must list added_by,
  added_at, and added_rationale in intake.yaml or metadata.yaml.
- 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.

GRANT AND AWARD INGESTION (when packet includes grants, awards, or ORS listings):
- Read docs/reports/grant-ingestion-governance.md.
- Unresolved knowledge is still knowledge: evidence-backed awards MAY enter
  data/grants.yaml even when PI is not in people.yaml.
- Treat three questions separately: (1) grant existence, (2) PI identity
  resolution, (3) facility/resource linkage.
- person_identity_status: resolved | unresolved | ambiguous — never invent person_id.
- resource_links_status: resolved | unresolved | not_supported — facility edges
  require explicit lab/facility naming in source.
- Add person_grant_links.yaml ONLY when person_id is resolved.
- Add grant_resource_links.yaml ONLY when resource link is resolved.
- Do NOT discard awards solely because PI is absent from people.yaml.
- Report counts: grants added (resolved PI vs unresolved PI), PGL added, GRL added,
  deferred unresolved rows indexed in packet extracted/.


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 | resource links.
- person_grant_links.yaml only when person_id is resolved.
- grant_resource_links.yaml only when facility naming is explicit and resolved.
- Report resolved vs unresolved PI counts in refactor_output.md section B.

AUDIT-DRIVEN REFACTORS (if implementing docs/reports/*-audit.md findings):
- Follow docs/reports/audit-driven-refactor-policy.md.
- Audit findings are NOT evidence; every change needs in-repo or packet source.
- Prefer surfacing/linking existing YAML evidence over new factual claims.
- Incremental diffs; preserve readability; stop before commit unless instructed.

Task:
Propose evidence-backed edits to the EXISTING corpus that reflect the supported
claims in this packet's evidence_checklist.md. Target resources: EXT-011, data/grants.yaml GRA-034–036.

Strengthen the network of evidence-backed relationships — do not simply append
isolated facts. The Resource Map is a hypertext knowledge system.

Rules:
- 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)
- Do NOT edit anything under docs/ — it is a generated mirror (sync_docs.sh regenerates it).
- Do NOT run sync_docs.sh, mkdocs, or graph export. Stop at proposed file edits.
- Every change must cite a source present in this packet. No claim without evidence.
- Never invent URLs, emails, dates, confidence scores, or person IDs.
- Preserve existing resource IDs; assign new IDs sequentially per resource-map-index.md; never reuse.
- Keep access evidence in resource_access.yaml and verification evidence in resource_verification.yaml.
- When evidence is incomplete, set verification status to needs_review (do not inflate confidence).
- Respect display vs graph separation (include_in_public_site / include_in_graph) and the
  "what the system refuses to assume" rules (shared unit ≠ collaboration, affiliation ≠ use,
  keyword match ≠ proof).
- Honor the `do_not` list in intake.yaml (or curator guidance in metadata.yaml).

--------------------------------------------------
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 (include unresolved-PI grants: index in packet extracted/, propose grant rows when source is reliable)
G. Relationships considered but rejected
H. Evidence supporting every accepted relationship
I. Any provenance concerns
J. Any conflicts with existing repository content
K. Audit implementation summary (when applicable — see audit-driven-refactor-policy.md):
   relationships surfaced, hyperlinks added, reciprocal links added, evidence used,
   recommendations not implemented and why

Write the report to refactor_output.md in this packet unless instructed otherwise.

--------------------------------------------------
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, then run:
  ./sync_docs.sh && .venv/bin/mkdocs build --strict
```

---

## After the refactor

1. Update `intake.yaml` `status:` to `refactored`, then `in_review` (or workflow fields in `metadata.yaml`).
2. Reviewer checks the Git diff against `evidence_checklist.md` and `refactor_output.md` section A (captured vs used sources).
3. On approval, run `./sync_docs.sh` and `mkdocs build --strict`.
4. Only after a clean, tested build does work move toward `main`.