Problem / gap
There is no cohesive adopter-facing guide for an institution that wants to stand up LIF for its own use. Today the docs serve two audiences — contributors (root README dev setup, CONTRIBUTING, testing) and LIF-Initiative-internal operators (docs/operations/guides/deployment.md, demo-promotion cheatsheets — all keyed to our AWS dev/demo via SAM/CloudFormation/ECR). The "adopter" persona is named in scattered places but never given an end-to-end path.
The entire adopter deployment story today is a single paragraph in deployments/README.md ("fork the repo, make your own deployments/ subdir").
What exists (building blocks to reuse)
deployments/advisor-demo-docker/ — the one shipped, local compose targetdocs/operations/guides/add-data-source.md, creating-a-data-source-adapter.md — source integration recipesdocs/overview/mdr-overview.md, docs/lif-data-model-distinctions.md, docs/specs/data-model-rules.md — data-model customizationdocs/design/cross-cutting/self-serve-tenant-auth.md, docs/operations/guides/graphql-api-keys.md — auth/tenancydocs/overview/services-overview.md — building-block framing
What's missing
- An adopter entry point (root README only offers the local demo)
- A reference deployment topology beyond the local demo + sizing guidance
- The connective narrative: prerequisites → topology → stand up stack → define data model in MDR → connect sources → auth/tenancy → operate/upgrade
Proposed deliverable
A hub-and-spoke guide docs/operations/guides/deploying-lif-at-your-institution.md:
- Audience & prerequisites
- Choose your deployment shape (local eval → single-node → cloud/multi-org)
- Stand up the stack
- Define your data model in MDR (links existing model docs)
- Connect your data sources (links existing adapter guides)
- Auth, tenancy, and API keys (links existing auth docs)
- Operate & upgrade
Mostly assembly + linking of existing guides, with the 3–4 genuinely missing sections written fresh. First PR lands the structure with spokes wired and gaps explicitly stubbed/flagged; missing spoke docs (e.g. a portable cloud topology, dev-environment-bootstrap.md) tracked as follow-ups.
Type
Problem / gap
There is no cohesive adopter-facing guide for an institution that wants to stand up LIF for its own use. Today the docs serve two audiences — contributors (root README dev setup, CONTRIBUTING, testing) and LIF-Initiative-internal operators (
docs/operations/guides/deployment.md, demo-promotion cheatsheets — all keyed to our AWS dev/demo via SAM/CloudFormation/ECR). The "adopter" persona is named in scattered places but never given an end-to-end path.The entire adopter deployment story today is a single paragraph in
deployments/README.md("fork the repo, make your owndeployments/subdir").What exists (building blocks to reuse)
deployments/advisor-demo-docker/— the one shipped, local compose targetdocs/operations/guides/add-data-source.md,creating-a-data-source-adapter.md— source integration recipesdocs/overview/mdr-overview.md,docs/lif-data-model-distinctions.md,docs/specs/data-model-rules.md— data-model customizationdocs/design/cross-cutting/self-serve-tenant-auth.md,docs/operations/guides/graphql-api-keys.md— auth/tenancydocs/overview/services-overview.md— building-block framingWhat's missing
Proposed deliverable
A hub-and-spoke guide
docs/operations/guides/deploying-lif-at-your-institution.md:Mostly assembly + linking of existing guides, with the 3–4 genuinely missing sections written fresh. First PR lands the structure with spokes wired and gaps explicitly stubbed/flagged; missing spoke docs (e.g. a portable cloud topology,
dev-environment-bootstrap.md) tracked as follow-ups.Type