DePaul Resource Map

← All packets

2026-06-14-circle-report-2024

Location: sources/inbox/2026-06-14-circle-report-2024/

Submission

Title
CIRCLE Report 2024
Submitter
Eric Landahl (elandahl@depaul.edu)
Unit
Physics
Submitted
2026-06-14
Description
Curriculum Integrating Research and Creative Learning in Education (CIRCLE) 2024 annual report from ORS (one off, only done in 2024)

Source

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

Workflow

Intake status
submitted
Review status
not_reviewed
Refactor status
not_started
Priority
normal
Created at
2026-06-14T05:50:54.014876+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-circle-report-2024

> 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` (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-circle-report-2024/

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-circle-report-2024/metadata.yaml (or intake.yaml if present)
- sources/inbox/2026-06-14-circle-report-2024/submitter_notes.md (or curator_notes.md)
- sources/inbox/2026-06-14-circle-report-2024/review_notes.md
- sources/inbox/2026-06-14-circle-report-2024/evidence_checklist.md
- every file under sources/inbox/2026-06-14-circle-report-2024/uploads/
- docs/source-packet-workflow.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.

--------------------------------------------------
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. Summary of sources reviewed
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.