Skip to content

What We Publish Here

Diátaxis: reference

This page defines the publication boundary for the public GiveCare Wiki.

This wiki is the canonical public reference for how GiveCare thinks — the conceptual model, methodological rationale, evidence base, validation posture, and limits of the system.

It is not a public data room, a partner diligence room, or a full dump of operational internals.

That distinction matters. The goal is to make GiveCare legible, inspectable, and accountable without publishing every metric, heuristic, or implementation detail that sits behind production systems.

The short version

We publish:

  • process
  • methodological rationale
  • theoretical underpinnings
  • reference research
  • validation status
  • known limits and open questions
  • conceptual architecture

We do not publish by default:

  • production usage metrics
  • retention / completion / engagement stats
  • partner-specific outcomes
  • prompt text or tool-routing internals
  • incident details tied to identifiable operations
  • exact thresholds, coefficients, or heuristics when they are gameable or competitively sensitive

The three publication layers

Think of GiveCare documentation as three concentric layers.

Layer Audience Purpose Typical contents
Public wiki Caregivers, partners, grant reviewers, clinicians, curious readers Explain what GiveCare is claiming and why those claims are reasonable Constructs, frameworks, research synthesis, validation posture, conceptual flows, limits
Private diligence pack Qualified partners, funders, evaluators Support deeper review under controlled sharing Pilot summaries, selected outcome metrics, process evidence, implementation detail needed for diligence
Internal docs GiveCare team Operate, tune, and improve the system Production metrics, thresholds, prompts, evaluator internals, failure analysis, partner-specific context

The public wiki should be the ground truth about the model, not the full picture of operational performance.

What belongs on the public wiki

A topic usually belongs here if it helps a reader answer one of these questions:

  • What is GiveCare claiming?
  • Why does that construct exist?
  • What evidence or theory informs it?
  • What is validated, adapted, original, or still provisional?
  • What are the known limits?

Examples that belong on the public wiki:

  • Why GiveCare uses a six-zone caregiver model
  • Why caregiver SDOH differs from patient SDOH
  • Why a given assessment was chosen or adapted
  • Which parts of a score are externally validated vs GiveCare-original
  • Why crisis routing is layered the way it is
  • Why SMS is the primary delivery channel
  • What InvisibleBench is intended to measure
  • What a construct should and should not be used for

What usually stays out

A topic usually does not belong on the public wiki if publishing it would:

  • reveal sensitive operating performance,
  • expose partner-confidential information,
  • make the system easier to game,
  • hand over implementation details that are strategically meaningful, or
  • create the impression that public methodology pages are the full operational record.

Examples that usually stay out:

  • active-user counts or growth curves
  • assessment completion rates in production
  • retention, response, or conversion metrics
  • partner-specific results or case studies without explicit approval
  • exact prompt text
  • model routing logic at the level needed to reproduce production behavior
  • incident reviews with operationally sensitive detail
  • thresholds or coefficients that are actively tuned and strategically important

Publish the rationale, not always the tuned value

When a topic is methodologically important but the exact tuned value is sensitive, publish:

  • the construct,
  • the reasoning behind it,
  • the direction of the decision, and
  • the limits or caveats,

without necessarily publishing the exact operational parameter.

For example:

  • Public: why emotional wellbeing or social support may receive greater conceptual emphasis

  • Private/internal: exact live weighting coefficients if they are still being tuned or are competitively sensitive

  • Public: why a sharp decline in caregiver state should trigger follow-up

  • Private/internal: the exact production threshold if disclosing it would make the system easier to game

Default to abstraction over omission. If a concept is important, explain it. If the live number is sensitive, keep the explanation public and the tuned parameter private.

Standard 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 heuristic,
  • and a hypothesis still under study.

Page pattern for core constructs

For any important public construct — 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
  • Implementation note (public conceptual summary only, where needed)

This keeps pages useful without turning them into operational playbooks.

The editorial rubric

Before publishing a claim or detail, ask:

First question: does this help an outside reader judge whether the system is thoughtful, evidence-based, and responsibly built?

If no, it probably does not belong here.

Second question: does publishing this materially expose secret sauce, sensitive operations, or gameable logic?

If yes, it likely belongs in a private or internal layer instead.

Third question: can the underlying idea be published at a more abstract level?

If yes, publish the rationale and keep the tuned parameter private.

Fast decision table

Question Public wiki Private diligence Internal only
Why this construct exists Yes — —
Theory and reference research Yes — —
Validation posture and caveats Yes — —
Production usage metrics No Yes, selectively Yes
Partner-specific outcomes No Yes, selectively Yes
Exact prompts and orchestration internals No Rarely Yes
Exact tuned thresholds or coefficients Sometimes — only if stable and non-sensitive Yes, selectively Yes
Conceptual safety architecture Yes — —
Incident review details No Sometimes, selectively Yes

What this means for measurement pages

For pages about the GiveCare Score, the caregiver SDOH 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,
  • do not assume the public page must include every operational 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."

That is enough. The public wiki does not need to make every internal operating detail visible to be credible.