Skip to content

Help without lock-in

HELP

Foundation is designed to be self-supported, and the help model reflects that. There is no Foundation support desk, no account to open and no contact form on this site — inventing one would imply a service that does not exist. What is genuinely available is below.

  • The documentation ships with the code in the public repository, so it cannot drift away from what it describes.
  • Three legitimate routes — your own work, your own developer or agency, or optional Provelopment assistance — with no recommended winner.
  • Nothing described here is gated, and nothing on this page promises a response time.

Three legitimate routes to help

These are the routes people actually take, and they are equally valid. Nothing on this page privileges one of them: the site you end up with is the same one whichever you choose.

  • Help yourself

    The public repository is the primary help channel for Foundation. Its documentation is written to be followed rather than skimmed, and it is versioned beside the code it describes.

  • Use your own developer or agency

    Because everything a deployment is expected to change lives in configuration, content and assets rather than in platform code, a Foundation site can be picked up by any competent web developer — including one who has never seen Foundation before.

  • Ask Provelopment

    Provelopment can provide implementation help, technical assistance, support and managed services for organisations that want them. That assistance is separate from the foundation and entirely optional.

None of the three is the recommended route. Bringing in help — or going without it — is a service decision you can make, or reverse, at any time without changing the software.

The documents that own the answers

Technical questions are answered in the repository, beside the code the answer describes. Each document below is authoritative for its subject, which is why this page does not repeat them.

  • README

    What the project is, how to start, the repository layout and the real validation commands.

  • CUSTOMIZING.md

    The downstream user guide and the complete configuration reference, including the table that separates what is yours from what is the platform's.

  • ARCHITECTURE.md

    Architectural style, boundaries, dependency direction and integration patterns.

  • DEPLOYMENT.md

    The launch runbook: first deployment, continuous-integration gating, custom domain and the post-deployment checks.

  • BRAND_ASSETS.md

    The brand-asset swap contract: every replaceable graphic role, in the order to replace them.

  • instruction-manuals/

    The procedures: adoption, customisation, branding, content, validation, deployment, upgrade and troubleshooting.

  • troubleshooting.md

    The recurring failures and their safe resolutions, including the ones that appear after an upgrade.

If this website and the repository ever disagree, the repository is correct. This page explains where to look; the repository performs the work.

Which source answers which question

Most visitors arrive with one of a small number of questions. These are the destinations that answer them, and none of them requires an account or a conversation.

  • What is Foundation, and what does it provide?

    The project's own explanation of its scope, its boundaries and how the parts behave.

  • How is it put together technically?

    The layers, the dependency direction and the boundaries the tests enforce.

  • How do I adapt a site to my own business?

    Identity, branding, content, dictionaries and assets, and which files are yours to change.

  • How do I get it live?

    The deployment runbook: the first deploy, the custom domain and the checks to run afterwards.

  • What does a finished Foundation site look like?

    Two running demonstrations built from the same foundation, with different content, identity and navigation.

  • Something is wrong with my own site.

    The troubleshooting procedure owns the problems that have actually recurred, each with a safe, proven resolution; the validation procedure defines what a passing check means.

  • I would rather someone else implemented or supported it.

    Provelopment's own site describes what it provides. That arrangement is made separately from the project.

This page deliberately does not reproduce the manuals. It points at them, so each answer keeps exactly one authority.

If you are stuck right now

Most problems with a Foundation site are configuration problems, and the foundation is built to report them rather than hide them. Work down this list before assuming something is wrong with the project.

  1. Run the validation gate and read the failure

    Configuration problems are reported at build time with the setting named, which resolves most issues immediately. The README names the commands that the project itself runs.

  2. Read the troubleshooting procedure

    The manuals include the recurring failures and their safe resolutions, including the ones that appear after an upstream upgrade.

  3. Check what changed, if you have just upgraded

    The upgrade procedure records what moves between Foundation versions and which files are the adopter's, which explains most problems that appear immediately after an upgrade.

  4. Ask whoever is building your site

    If someone is implementing or maintaining the site for you, they have the deployment in front of them and are the fastest route to an answer.

No step here depends on contacting Provelopment, and no step has a response time attached to it.

If you want help, it is available

Provelopment can provide implementation help, technical assistance, support and managed services for organisations that want them. That assistance is separate from the foundation and entirely optional.

  • It is arranged separately from the project: there is nothing on this website to sign up to.
  • Nothing in the software, the documentation or the running demonstrations depends on it.
  • Using it, or deciding never to, changes nothing about what Foundation is.

Foundation first, on its own terms; assistance afterwards, if you want it.

What open-source adoption does not include

The honesty of a help model matters as much as the routes in it, so this page states its limits rather than leaving them to be inferred.

  • No support desk and no guaranteed response: nothing described here is staffed, and this website does not accept support requests.
  • No service level, incident response or uptime obligation: you run your own deployment, and the software is provided without warranty.
  • No maintenance contract: absorbing upstream improvements is a documented procedure that you or your developer perform.
  • No gated documentation and no paid tier: every document described on this page is public, and the code is Apache-2.0 licensed.
  • No implied obligation on Provelopment: optional assistance is a separate service arrangement, not a prerequisite for the software to work.

What is available is the work in the repository, and — if you choose it — a separate service arrangement. Nothing else is implied.

Start where your question is

Read the document that owns your question, look at a running demonstration, or take the adoption route when you are ready to build.