Foundations
Start here for Solum product concepts, access rules, feature boundaries, and documentation conventions.
The foundation guides explain Solum vocabulary and access rules. Start here before you troubleshoot hidden controls, gated actions, team roles, or features that are not available yet.
Solum documentation is written for users and support-facing operators. It should be detailed enough to answer "why can I not see this?" without exposing internal admin, import, or catalog management procedures.
What this section covers
| Page | Use it when... |
|---|---|
| Getting started | You need the product overview, audience, main navigation, and first tasks. |
| Access, permissions, and missing controls | A user can sign in but cannot see a button, page, team card, upload control, billing card, or admin link. |
| Current feature boundaries | You need to decide whether a feature is available, limited, assisted, planned, or internal. |
Core documentation rules
Describe what the user can actually do
Describe a feature as available only when the intended user can complete the task in Solum.
For example, buyers can submit inquiries from development pages. Do not describe a full builder lead inbox until builders can complete that task in the product.
Explain permission gates early
Restricted actions should name the required state before the steps begin:
| Requirement type | Example |
|---|---|
| Authentication | Sign in to download development documents. |
| Team membership | Join the correct team before opening team tools. |
| Team role | Billing users can open billing but cannot manage builder media. |
| Linked builder profile | Builder teams need a linked builder profile before profile and development media tools are useful. |
| Platform role | Admin Panel is for Forcir operator roles, not ordinary team roles. |
Separate public, team, and internal language
Solum has public buyer pages, signed-in team pages, and internal operator tooling. These docs intentionally focus on the first two categories.
Use "Ask Forcir for help" when a task requires staff assistance. Use "internal" when a task belongs to admin, import, or catalog operations that should not appear in user-facing docs.
Audience map
| Audience | Typical need | Best starting point |
|---|---|---|
| Buyer | Search, compare, download documents, or submit an inquiry. | Buyer workflows |
| Signed-in buyer | Download documents or manage personal account details. | Accounts and teams |
| Builder team member | Manage supported profile, media, document, billing, or promotion tasks. | Builder operations |
| Billing contact | Open Stripe billing, update payment details, review invoices, or manage promotions. | Billing and promotions |
| Support or onboarding operator | Diagnose missing controls or role problems. | Reference |
Before adding screenshots later
Screenshots should match these written expectations:
- The page route and navigation label are current.
- The visible role and team state match the guide.
- Hidden buttons are not shown in examples for users who should not see them.
- Test or seeded data is not exposed.
- Pricing, availability, and promotion amounts are not shown unless intentionally verified.
Until screenshots are added, these docs should carry enough detail for a user or support operator to complete the task using text alone.