Home/Library/Project Notes

Project Notes

Project notes track design decisions, open questions, revisions, and future directions.

Why Keep Notes Public

A project about credencing should model its own updateability. Project notes can show what is settled, what is provisional, what changed, and what remains unresolved.

This is especially important because the site criticizes insulated confidence. A public project that asks readers to revise should make its own revisions visible enough to be trusted.

Current Design Decisions

The site currently treats the original interactive page as the central focus and builds the surrounding web as an interpretive layer. That keeps the model visible while giving readers multiple entry points: glossary, case studies, skills, applications, papers, and author context.

The custom domain, public GitHub Pages deployment, downloadable teaching materials, search, breadcrumbs, related links, and contact form all support that structure. The design aim is a public research-and-teaching site rather than a private note archive.

Open Questions

Open questions now begin downstream of the current paper spine. The project still needs better methods for estimating model variables in real cases, distinguishing sincere misperception from avoidant misperception, preventing diagnostic overclassification, and deciding when a new idea deserves its own paper rather than a revision to an existing page.

Other open questions include how numerically precise the model should become, how to validate archetype assignments, how to handle disagreement among competent observers, how to represent confidence bands in public language, and how to teach the framework without encouraging overconfident diagnosis of others.

The next project layer should favor artifacts that make credencing inspectable: audit worksheets, update logs, likelihood-comparison exercises, confidence-band templates, AI-output review protocols, and institutional evidence-trail formats.

Revision Norms

Revision is treated as evidence of health rather than embarrassment. The site should preserve enough history to show how the framework improves.

A good revision note states what changed, why it changed, which pages were affected, and whether the change alters the model or merely clarifies language. This keeps readers from mistaking polished presentation for finality.