Order of authority
What every public page should answer
| Question | What the page should show |
|---|---|
| What is this? | A plain description of the page. |
| Who is it for? | The readers the page is meant to help. |
| What can I do here? | One clear purpose. |
| Is it current? | A date or status when the information can age. |
| Where did it come from? | Sources and any limits on verification. |
| What comes next? | A small set of useful related pages. |
| How can I correct it? | A visible correction route. |
Seven publication checks
Authority
Is this appropriate and authorized for public use?
Protection
Could publication expose cultural, family, medical, personnel, or confidential information?
Verification
Are the source, date, claim, and uncertainty shown accurately?
Purpose
Does the page do one clear public job?
Focus
Does the page stay at one level and link out when more explanation is needed?
Aging
Does the page show when its information may become stale?
Correction
Can readers report an error or missing source?
Interface integrity checks
Readable structure is part of reliability. Labels, dates, contacts, and actions should remain legible without forcing readers to reconstruct words or guess which value belongs to which label.
- Do not split ordinary label words. Definition-list labels such as Coordinator, Government, Transportation, and Eligibility stay intact.
- Stack before squeezing. Weekly fact rows become one column on narrow screens instead of compressing the label column.
- Wrap values, not labels. Long phone numbers, email addresses, links, and descriptive values may wrap inside their own column.
- Check current and archive copies. Layout corrections apply to the dated Check-In,
latest.html, downloadable copies, and archived issues that reuse the component. - Validate document structure. Public HTML should have one doctype, no duplicate IDs, no missing local references, and no case-collision paths before packaging.
Weekly Check-In editorial integrity
The weekly board is cumulative, not disposable. New information is added without silently dropping recurring service, jobs, education, safety, food, housing, transportation, or planning doors that remain current and useful.
- Strict-source gate for high-stakes items. Money, legal status, safety, health, jobs, services, and policy items need an original or authoritative public source plus a public contact or identifiable official host. If either side of that gate is missing, the item is held rather than forced into the board.
- Community-good-faith gate. Cultural events, celebrations, fundraisers, sports, youth achievements, markets, and community shares may use a public community source when an official page is unavailable. Use the standard disclaimer exactly once: Shared in good faith to support community visibility — please confirm details directly with the individual or family. Do not stack multiple versions of the same disclaimer.
- No certainty inflation. Community-good-faith items do not use “official,” “verified,” “confirmed,” or “guaranteed” as certainty labels.
- Source and host stay visible. Each actionable item carries a source; the public contact or host is shown where available and especially where a reader may need to register, travel, apply, or ask a question.
- Continuity removals need a reason. A recurring item leaves the current board only when it expires, becomes inaccurate, is superseded, or no longer serves the weekly board.
- Freshness labels match the real edit history. If content is added after the main source-check date, the visible issue label shows both the source-check date and the later update date. Structured metadata such as
dateModifiedmust match the visible update date. - Status reporting is not advocacy. Legislative and policy cards report procedural status and source limits without adopting a candidate, party, bill, or advocacy campaign position.
Check-In calendar standard
The calendar is a navigation layer, not a second source of truth. It helps readers see dated items without replacing the item card, source line, or controlling public record.
- One dataset, multiple views. The at-a-glance calendar and section calendars must render from the same curated dated-item record so dates do not drift between interfaces.
- Do not invent dates. Ongoing services without a specific date remain in the cards and are not forced onto the calendar.
- Expected dates stay labeled. Projected school-board or recurring dates must remain visibly distinct from posted or confirmed dates.
- Mobile first. Calendar controls must be finger-sized; day cells may reduce event names to color dots on narrow screens, with full detail exposed after selection.
- Motion is optional. Spotlight and shine effects must respect
prefers-reduced-motion; interaction and meaning cannot depend on animation or hover. - Offline copies work. The dated issue,
latest.html, and downloadable issue carry the same calendar data and controls without requiring a framework or external runtime. - Future weekly rollover. New Check-Ins update the calendar record as part of the continuity gate; expired dates may remain in the archived issue but must not be silently carried into a later issue.
What “include it all” means here
The site publishes only material that is public, authorized, appropriate, and safe to share. Other material is governed or withheld before publication. Clear filters are then used over the public record.