Factual Information Audit¶

Purpose¶

This is the intake list for information still needed across the documentation site. It separates missing facts from reusable templates so contributors know what to research, who should approve it, and whether the resulting information may be public.

The September 2, 2026 audit found 72 Markdown pages: 24 Active and 48 Draft. Thirty Draft pages are intentionally blank chapter contribution shells. Draft status does not necessarily mean a page is wrong; it means the owner still needs to confirm facts, policy, examples, or operating details.

How to close an item¶

For each factual addition, provide:

the exact statement or value;
its effective date or term;
an authoritative source or approving owner;
whether it is current, historical, proposed, or an example;
the appropriate information tier;
the public-safe wording, if the source is restricted; and
a future review date and role owner.

Prefer primary sources: approved governing documents, official National decisions, chapter records, organization-controlled repositories, signed agreements, published chapter sites, and direct confirmation from the responsible portfolio. A contributor recollection can start a draft but should be labeled until an owner approves it.

Priority 0 — needed before expanding the KTP Life App beta¶

Fact or decision needed	Why it matters	Public result	Restricted source/record	Owner to confirm
Official product name	The portal has used “National Life App,” “KTP Life App,” and “Kappa Theta Pi Mobile App”	One name and short purpose statement	Naming decision and product registry	National Technology and Branding
Canonical client, backend, calendar-sync, and dashboard repositories	Contributors cannot know which code is authoritative	Organization/repository names when public	Private URLs, administrators, recovery, and credentials	National Technology
Product owner, engineering lead, product/design lead, and release authority	Decisions currently have no named accountable role	Approved role/title and responsibility	Personal contact and access records	President and National Technology
Current TestFlight build/version and beta start date	Testers need to report against the correct build	Current build label, status date, and safe release note	TestFlight administration	Release Engineering
Participating chapters, tester eligibility, and capacity	Beta onboarding cannot be applied consistently	Approved participant description	Tester roster and invitation records	Chapter Success/Beta Operations
Android and web support status	Current TestFlight status covers iOS only; other targets are unclear	Supported-platform matrix	Internal compatibility evidence	Product and Engineering
Beta feedback and urgent-incident routes	Reports need one owner and severity path	Public role-based route when available	Private form, queue, on-call, and evidence	Support and National Technology
Production exit criteria	“Beta” has no shared definition of complete	Approved readiness checklist	Detailed release evidence and risk acceptance	Product Council and release authority
Member privacy notice and data map	The app processes profiles, contact data, résumés, events, RSVP, attendance, and device tokens	Plain-language member notice and safe data summary	Field inventory, administrators, retention, incidents, and policy	Data owner, IAM, and National leadership
Résumé visibility and external-use rule	Upload support exists, but viewing and sharing authority need confirmation	Who may see a résumé and how a member controls it	Access-policy implementation and audit	Product owner and data owner
Server authorization and backend reproducibility	Client interface checks are not a security boundary	High-level assurance and ownership	Versioned migrations, authorization policies, tests, deployment, and incidents	IAM and DBA
Organization ownership of Expo, app stores, backend, CI, and signing	Personal-account concentration creates continuity risk	Organization owner and responsible role	Administrators, signing, billing, and recovery	National Technology and Finance
Team assignments	Proposed teams have no chapters or leads assigned	Lead/partner chapter and approved public role names	Access groups and personal contacts	National Technology and President

KTP Life App team intake¶

For every team in the Teams and Ownership model, provide:

official team name and charter;
lead chapter and partner chapter;
National sponsor;
primary and backup lead roles;
appointment term and rotation date;
expected hours per week and busy periods;
eligibility and selection method;
repositories, environments, and data categories needed;
decisions the team may make without additional approval;
required reviewers and release gates;
meeting and reporting cadence;
named facilitator, recurring time, attendance expectations, agenda owner, and notes location for the weekly IAM, DBA, and Product Leads meetings;
semester deliverables and success measures; and
handoff and access-removal owner.

Do not publish personal contact details, private team invitations, production access, or service-administrator lists.

Chapters — 30 contribution pages¶

Every current chapter page is an intentionally brief Draft shell. Each chapter should submit these public-safe facts through a merge request:

Needed from each chapter	Context to include
Approved chapter bio	Campus community, chapter focus, distinctive programming, and intended audience
Greek designation and exact founding/charter date	Date type, source, and whether founding and chartering differ
Current standing	Meaning of the status, effective date, and approving source
Official chapter website or public profile	Owning role and most recent link check
Current EBoard	Approved public names, exact titles, term dates, and chapter consent for publication
Semester entries	Term, EBoard, 3–6 event or operating highlights, outcome, what changed, and reusable lesson
Enduring practices	Tradition or system, why it works, when another chapter should adapt it, and known constraints
Source note	Chapter record or public source used and date checked

The directory also needs exact founding dates where it currently uses a range such as “before 2016,” plus confirmation of chapters with no public website.

National history and Board archive¶

Needed fact or context	Current gap
Exact term dates for every National Board	Board labels exist, but some start/end dates and transition dates need confirmation
Board selection and transition method	The archive lists people and roles without explaining how each board took office
Inaugural Board evidence	Confirm Constitution ratification date, participating chapter count, approved version, alumni-database milestone, and scope expansion date
Second Board revenue milestone	Confirm semester/date, whether the $50 payment was per member or another unit, collection authority, and aggregate outcome safe to publish
Merchandise store	Confirm launch date, public store route, vendor name if approved, ownership, and outcome
First National Convention	Confirm official event name, date, location/format, attendance, participating chapters, program archive, and who may publish photos or recordings
Speakers and workshops	Confirm approved titles, session names, biographies, recordings, and consent to keep names public
Current Board contributions	Replace placeholder rows with completed initiatives, measurable results, owner, and source
Future board archive process	Name the role responsible for collecting roster, contributions, evidence, and publication approval each term

Use board-level outcomes rather than attributing every shared result to one person unless the attribution is approved and evidenced.

National organization and governance¶

Exact authority for each portfolio, including financial thresholds and decisions reserved to the full Board.
Current role owners, term dates, and organization-controlled contact routes.
National meeting cadence, attendees, quorum where applicable, and location of approved agendas or summaries.
Formal reconsideration or appeal procedure for chapters.
Constitution version, effective date, amendment log, and public availability decision.
Policy register showing owner, approver, effective date, review date, and affected chapters.
Chapter status definitions and the authority that changes a status.
Official National program calendar and owner.

Chapter semesterly compliance¶

The process is documented, but the following facts are still required before it becomes an enforceable policy:

fall and spring deadlines, time zone, grace period, and correction deadline;
effective term and approving National authority;
approved restricted submission system and acknowledgement behavior;
reviewer and escalation owner for each of the four requirements;
downloadable alumni spreadsheet and version history;
downloadable financial-audit workbook, categories, acceptable supporting evidence, and reconciliation policy;
member-audit snapshot date and definitions of active, inactive, pledge, alumni, and other included statuses;
approved purpose, notice or consent, visibility, external sharing, retention, correction, and deletion for names, email addresses, majors, and résumés;
check-in scheduling route, National attendee, cancellation/rescheduling rule, and completion record; and
consequences and remediation process for missing or incomplete submissions.

The completed files and private submission links remain National-restricted even if blank templates and instructions are public.

Alumni database¶

Official platform and authoritative database owner.
Whether the app database, alumni database, and semester alumni spreadsheet are one system or synchronized systems.
Approved field dictionary and required/optional fields.
Alumni notice or consent and communication-preference rules.
Who may search, export, correct, merge, restrict, and delete a record.
Retention after graduation, inactivity, opt-out, or platform retirement.
Chapter update schedule, deduplication rules, and confirmation process.
Approved mentorship, speaker, recruiting, and outreach uses.
Aggregate success measures and annual data-quality owner.
Restricted incident, access-request, and alumni correction routes.

Chapter operating calendar and officer guides¶

Official fall and spring membership-reporting dates.
Approved election windows and deadline for reporting new officers.
Budget, dues, financial-reporting, and compliance dates.
Chapter health-review owner, required content, and review window.
Officer training and transition requirements.
National convention, hackathon, forum, and program dates.
Which recommendations are National standards versus adaptable examples.
Exact local title mapping for roles such as VP External Affairs, Outreach, Finance, and Member Development.
Public-safe success measures from real chapters to replace generic guidance over time.

Starting a chapter¶

Official application route and Chapter Growth contact method.
Eligibility, minimum founding-team or member expectations, and campus-recognition prerequisites.
Colony stages, typical duration, required check-ins, and readiness rubric.
Governing documents and templates supplied to colonies.
Any fees, dues, insurance, training, or financial requirements.
Mentor assignment and expectations.
Who recommends, votes on, and formally approves a charter.
Required evidence, exception process, and decision timeline.
Official chapter naming, Greek-letter assignment, and public launch process.
First-semester National and school obligations after chartering.

Until approved, the existing colony roadmap should remain supportive guidance rather than being described as binding policy.

Outreach and sponsorship¶

Sponsorship packet owner, approval date, covered term, next review, and whether it remains the current National example.
Which sponsorship offerings, prices, and benefits are National-approved versus chapter-customizable.
Contract-signing authority, financial approval thresholds, and data-sharing restrictions.
Process for avoiding duplicate National/chapter outreach to the same company.
Public role-based contact route for interested companies.
Approved use and owner of Teagan's sample response emails.
Public-safe partner outcomes or case studies with dates, event format, attendance range, and consent.
Resource-link owner and review cadence so expired programs are removed.

Keep contracts, negotiation history, unpublished pricing, personal recruiter contacts, and restricted company terms out of the public repository.

Events and programming¶

The event library is still Draft. Chapters should add real, public-safe examples with:

event title, category, term, and contributing chapter;
intended audience and outcome;
preparation lead time and officer/committee owner;
attendance or participation range;
public-safe budget range;
accessibility and risk considerations;
what worked, what failed, and what changed next time;
reusable materials cleared for publication; and
partner/speaker attribution only when approved.

Documentation and public-site governance¶

License for documentation and code, plus permission to reuse contributions.
CODEOWNERS or equivalent primary and backup reviewers.
Public security-reporting route and restricted incident route.
Documentation style and terminology decisions, including “EBoard,” “E-Board,” and official app naming.
Evidence standard for historical claims and personal attribution.
Page review cadence, stale-page definition, owner, and archival process.
Accessibility standard for pages, templates, downloads, images, and video.
Copyright and permission status for the KTP logo, sponsorship packet, speaker materials, and contributed assets.
Whether analytics or other tracking is used and whether a public notice is required.
Source/build policy for committing the generated site/ directory.

Recommended collection order¶

App beta facts and data governance — needed before more chapters and member data enter the product.
Compliance policy and templates — needed before describing the four checks as enforceable.
National authority, dates, and contacts — needed to make routing and calendars authoritative.
Chapter page contributions — distribute one small merge request to each chapter.
Historical evidence and outcome context — preserve sources while prior leaders are available.
Outreach, events, and operating examples — grow these continuously through semester retrospectives.
Repository governance — establish ownership, review, security, accessibility, licensing, and freshness.

Intake template¶

### Fact or decision

- Area/page:
- Exact public-safe statement:
- Status: Current / Historical / Proposed / Example
- Effective date or term:
- Source or approving owner:
- Information tier:
- Private source location, if any:
- Review owner and next review date:
- Notes or conflicts to resolve:

Public-content review¶

[ ] Restricted sources are summarized, not copied
[ ] Personal information and private contacts are removed
[ ] Dates, statuses, and owners have an effective term
[ ] Policy, guidance, proposals, and examples are labeled differently
[ ] Historical attribution has an approved source
[ ] Every current fact has a future review owner