Knowspread documentation
Use this documentation to understand how Knowspread is operated, configured, integrated, and maintained. The same product concepts are documented at different depths for different audiences:
- clients and prospects who need practical guidance,
- project owners who need rollout, QA, and operational control,
- integrators who need API contracts and synchronization rules,
- the internal team who needs architecture, edge cases, and source-of-truth behavior.
When a page depends on code or generated artifacts, it should state the source and, where practical, the commit or environment it was checked against.
Start here
Section titled “Start here”| Role or need | Start here | What you should get |
|---|---|---|
| Client stakeholder | Client documentation | Product concepts, rollout path, user management, reporting. |
| Project owner | Owner runbook | Launch checklist, routine checks, risk areas, escalation inputs. |
| Administrator | Users and groups | Roles, states, groups, assignments, common edge cases. |
| Integrator | API and integrations | REST API areas, identifiers, webhooks, error handling. |
| Developer or insider | Architecture overview | Main application surfaces, domain flows, and code entry points. |
| Reviewer | QA and acceptance | User-facing test scenarios and acceptance criteria. |
Product map
Section titled “Product map”flowchart LR CompanySpace[Company Space] --> Users[Users] CompanySpace --> Groups[Groups] CompanySpace --> CICS[Content in space] Groups --> Assignments[Content assignments] Users --> Assignments CICS --> Assignments Assignments --> Participation[User study record] Participation --> Reporting[Reporting and certificates] CICS --> Marketplace[Marketplace and licenses]
Documentation maturity
Section titled “Documentation maturity”Each important product area should eventually have four layers:
| Layer | Purpose |
|---|---|
| User guide | What a client or learner does in the UI. |
| Owner guide | How a client owner configures, checks, and governs the area. |
| QA guide | How to verify the behavior before rollout or after a change. |
| Internal notes | Architecture, invariants, source files, and known edge cases. |
This repository should not contain production application code, migrations, or short-lived working notes that are not useful as long-term documentation.