What We Share Here¶
This wiki explains GiveCare's public model: the caregiver needs we organize around, the evidence we rely on, the product decisions we can responsibly describe, and the limits of the current work.
It is meant to make GiveCare legible and accountable without turning a public resource into an operations archive. Readers should leave with a clear view of what GiveCare is claiming, why those claims are reasonable, and what still needs validation.
What belongs here¶
We publish material that helps caregivers, partners, clinicians, funders, and researchers understand:
- what GiveCare is trying to help caregivers do
- why a construct, score, safety layer, or workflow exists
- which evidence or public source supports a claim
- what is externally validated, adapted, original, or still provisional
- what the known limits are
- how a public resource can be used safely
Examples that belong on the public wiki:
- why GiveCare uses a six-zone caregiver model
- why caregiver social needs differ from patient social needs
- why a given assessment was chosen or adapted
- which parts of a score are externally validated versus GiveCare-original
- why crisis routing is layered the way it is
- why SMS is the primary delivery channel
- what InvisibleBench is intended to evaluate
- what a construct should and should not be used for
What usually stays out¶
Some information is not appropriate for a public wiki even when it is important to operating the product. We usually do not publish details that would:
- disclose private partner or caregiver information
- expose live operating performance before it is ready to share
- make safety or eligibility systems easier to game
- imply that public methodology pages are the full operating record
- publish implementation details that are not needed to understand the public claim
Examples that usually stay out:
- live usage, retention, response, or conversion metrics
- partner-specific results without approval
- private incident reviews
- exact prompt text
- routing logic at a level that could reproduce or game production behavior
- tuned thresholds or coefficients while they are still changing or sensitive
Publish the rationale, not every operating detail¶
When a topic is methodologically important but the exact live setting is sensitive, the public page should explain:
- the construct
- the reasoning behind it
- the direction of the decision
- the evidence and caveats
- the limits of the current implementation
For example, a public page can explain why caregiver stress or social support may receive conceptual emphasis without publishing every live weighting coefficient. A public page can explain why a sharp decline in caregiver state should trigger follow-up without exposing the exact threshold used in production.
Default to explanation over silence. If a concept matters, explain the idea clearly and keep only the sensitive operating detail out.
Disclosure labels¶
Public pages should distinguish clearly between kinds of evidence. Use labels like these when documenting assessments, scores, classifiers, or frameworks:
| Label | Meaning |
|---|---|
| Externally validated | Supported by published validation outside GiveCare |
| Adapted from validated frameworks | Built from established instruments or frameworks, but modified for GiveCare's context |
| GiveCare original | Designed by GiveCare rather than adopted from a published instrument |
| Operationally tested | Used in practice or internal evaluation, but not externally validated |
| Not yet externally validated | Important to disclose explicitly when a construct remains provisional |
These labels matter more than polished language. They let a reader tell the difference between a known instrument, an adaptation, a product heuristic, and a hypothesis still under study.
Page pattern for core constructs¶
For any important public construct, such as a score, assessment, framework, or safety layer, the ideal page shape is:
- What this is
- Why it exists
- Evidence base
- What is original here
- Validation status
- Known limits
- Public implementation note, if needed
This keeps pages useful without turning them into operating playbooks.
Editorial rubric¶
Before publishing a claim or detail, ask:
- Does this help an outside reader judge whether the system is thoughtful, evidence-based, and responsibly built?
- Does publishing this expose private information, sensitive operations, or gameable logic?
- Can the underlying idea be explained at a safer level of abstraction?
If the answer to the first question is no, the detail probably does not belong here. If the answer to the second question is yes, publish the rationale and keep the sensitive detail out.
Fast decision table¶
| Question | Public wiki | Controlled sharing | Not public |
|---|---|---|---|
| Why this construct exists | Yes | - | - |
| Theory and reference research | Yes | - | - |
| Validation posture and caveats | Yes | - | - |
| Public safety architecture | Yes | - | - |
| Production usage metrics | No | Sometimes | Yes |
| Partner-specific outcomes | No | Sometimes | Yes |
| Exact prompts and routing details | No | Rarely | Yes |
| Exact tuned thresholds or coefficients | Sometimes, if stable and non-sensitive | Sometimes | Yes |
| Incident review details | No | Sometimes | Yes |
What this means for measurement pages¶
For pages about the GiveCare Score, the caregiver social-needs assessment, or similar constructs, the public standard is:
- publish the construct definition
- publish the research and design rationale
- publish the validation status honestly
- publish the limits and intended interpretation
- avoid implying that the public page contains every operating metric or implementation detail
A strong public methodology page should let a careful reader say: "I understand what this is, why it exists, what supports it, what is original, and what still needs validation."