28 September 2026
Public identity: Lawrence Rowland — independent project experiments
Stage 1 is in progress. Stages 2–5 are proposed, independently useful improvements.

Purpose

Help a reader follow an open enquiry or understand a named solution to a particular problem: its example, construction, assumptions and limits.

The public work already contains strong material: a refuge halfway up a cliff, a circular brick wall, a wildlife crossing, shared access to a farm, and conflicting views of a project. These scenarios make difficult ideas approachable. Their emblems, mathematical diagrams, source trails and distinct investigations should survive the redesign.

Gradually give individual enquiries and solutions recognisable identities. Some belong within a foray; others may become successors to earlier portfolio-management work, hosted here or independently. A bounded worked example captures a useful solution, demonstration or proved property under particular assumptions at a recorded point in time. It does not mean project management is generally solved. These roles are not steps on one maturity ladder.

This is independent exploratory work. Do not recast it as a consulting service catalogue, claim organisational adoption, or introduce professional/client material to fill gaps. Preserve each artefact’s stated scope, source attribution and explicit reuse limits; public visibility alone is not a new licence.

A visual language already present in the work

Use generous pictured tiles as entrances, concrete scenario illustrations as orientation, and distinctive emblems for recognition. The recurring direction suggests a quiet working library: warm backgrounds, restrained colour, readable type and space for images. Carry a consistent navigation shell between different project worlds. Once inside, make the formal structure visible through diagrams tied to the model. Treat this as a design hypothesis to refine with Lawrence, grounded in the existing work and his stated preference for pictured tiles, rather than a claim to have discovered a fixed personal style.

Audit baseline and limits

The September inventory covered 61 repositories: 57 public and four private excluded from this review. It identified 25 Pages-enabled repositories, 18 entries in the public project directory, and checked 215 static URLs. The root-site audit recorded five 404 responses: three unlinked test/placeholder roots and two notes links. A separately sampled ontology download also failed.

Coverage combined repository metadata, public README and entrance review, representative downstream essays, static responses, and selected rendered journeys. It was not an exhaustive review of every application, mathematical claim, dependency, interaction or source permission. A successful HTTP response is not proof that an application works; automated model checks are not human-use or engineering validation.

No private repository names or contents belong in the public inventory. Retain the distinction between an active investigation, a completed checkpoint, a historical prototype, a reference library and a working utility.

Update after the first review

Lawrence explicitly requested retirement of CSV to Gantt as an earlier Operator demonstration whose purpose had passed. He deleted its repository; the repository and Pages address now return 404. Its directory entry is removed, leaving 17. This is an explicit exception to preservation, rather than a general instruction to delete less prominent work.

The directory now uses one pictured grid and topic filtering. “Featured projects” and “Playgrounds & libraries” mixed prominence, interaction and collection type, so they no longer divide the grid. Existing group fragment links are retained as aliases and the three Gimmer collections remain separate entries. Notes and About move to the footer; the small existing writing collection is reachable within Library.

Stage 1 — Establish the entrance

Current scope: homepage, shared header/footer and configuration; About openings; Notes orientation; a Library page using existing public guides; two confirmed notes-link repairs; a single project grid; and removal of the explicitly retired CSV-to-Gantt entry. Keep the remaining 17 directory entries and their application routes after the explicitly requested CSV-to-Gantt retirement. Import no private Vault material.

Make the homepage a curated entrance to open enquiries and bounded worked examples. Give visitors a few compelling scenarios and questions. Keep earlier portfolio/project-management guides, graphs, books and other heritage discoverable through Library, clearly dated and scoped where evidence permits.

Primary navigation is Projects / Library; Notes and About remain in the footer. Existing app collections remain accessible through a secondary footer disclosure; they no longer lead the identity. About explains the independent work; Notes explains the existing writing. Naming and migration beyond this first entrance remain gradual.

Acceptance

  • The opening identifies Lawrence and the work, presents an intelligible project question, and offers a clear first example on desktop and mobile.
  • Navigation destinations agree with their labels; retained published routes and all 17 directory entries remain reachable. The two notes repairs resolve to the intended content.
  • Keyboard navigation, focus, responsive layout and a complete example-and-return journey are checked. Verify the published revision and retain a rollback route before calling the stage complete.

Stage 2 — Make discovery useful

Test the editorial organisation on real questions before expanding the data structure. Examples include “What can happen next?”, “Why must this task wait?” and “What must one package provide before another starts?”

Then create a lightweight public registry: stable identifiers, names, memberships, entry routes, canonical URLs and sources. Separate reader role—open enquiry, bounded worked example, utility, reference or earlier collection—from evidence/review status. Detailed mathematics and evidence remain with the project. Record a worked example’s problem, assumptions and genuine capture/revision date; do not invent missing dates.

Keep the three Gimmer lanes distinct. Allow one artefact to have several useful entry routes: App 20’s scheduler and process-comparison views deliberately share an implementation. A shared refuge illustration does not mean Project Spines and Gimmer share an executable model.

Name individual solutions as their purpose becomes clear. Their parent may be a foray, this site or a standalone identity. Preserve original titles and numbers for retrieval; do not require every solution to become another app-collection tile.

Acceptance

  • All 17 retained entrances have stable records and working routes; distinct Gimmer lanes and meaningful queries/fragments are preserved.
  • Newcomer questions find useful enquiries or scoped examples; returning readers can still find original titles and identifiers. Role and evidence status are independent fields.
  • Status and dates state what was checked and when. Unknown review state remains unknown; fresh commits or HTTP checks do not silently become model-review claims.

Stage 3 — Connect each reading journey

Provide a lightweight route through scenario, first example, result, construction, sources and limitations, with reliable returns. An enquiry explains its open question; a worked example states the particular problem it addresses and the assumptions fixing its result. Neither needs a uniform layout or long banner.

Use Building a Wall as the reference. Pilot improvements on Bricklaying a Rotunda and Project Spines, then apply the lessons to Local to Global. This covers an essay catalogue, React/tabbed applications and a plural historical workbench.

Distinguish a newcomer’s starting point from the newest result. Rotunda currently promotes #13 while recommending #12 as the start. Project Spines has a tangible finite shed example but begins with theory. Both can support multiple readers without presenting competing instructions.

Acceptance

  • Each pilot supports a complete journey: understand the scenario, make one meaningful change, interpret the result, inspect a source or limit, and return.
  • The pattern works across static and tabbed/embedded pages without breaking deep links, controls or state expectations; check mobile and keyboard use.
  • Illustrations, computed results, source contributions and the author’s construction remain distinguishable. Preserve mathematical depth and report interface/model checks separately from human feedback.

Stage 4 — Give solutions identities without losing history

Peel off named solutions gradually, within existing forays or as successors to earlier work. Compare capabilities, assumptions and contributions before consolidating: similar names do not establish duplication. Distinguish exact copies, superseded attempts, alternative interfaces and distinct models. Keep heritage as bounded, useful examples of what was established at the time.

Render important Markdown method notes as readable companion pages while retaining their source/download routes. Preserve historical workings, curation explanations and recovery copies. Redirect only when there is a genuinely equivalent destination; archived material may remain the right destination.

Acceptance

  • Each naming or consolidation decision records the problem, assumptions, evidence, date if known, preserved history and suitable destination. No bulk migration is implied.
  • Old URLs, including meaningful queries/fragments, are checked after redirects; there are no loops or unexplained losses, and a recovery map exists.
  • Companion reader pages have working relative links/images, source access and collection returns. No source or distinct model is silently overwritten.

Stage 5 — Publish findings as notes

Add short dated notes for a finding, correction, counterexample, newly captured worked example or next question. Link them to the relevant named work and sources, with a return link. A new name does not upgrade its evidence or erase its earlier context.

Do not manufacture a publishing cadence, a “latest” feed from file timestamps, or new dates for unchanged historical writing. Notes should help readers understand how an investigation develops, without becoming a second conflicting results catalogue.

Acceptance

  • Each new note identifies its question, finding, supporting artefact and remaining uncertainty.
  • Publication and substantive revision dates are distinct and truthful; current activity or real-world success is not inferred from a checkpoint.
  • Reciprocal links make a useful next step clear, and the maintenance effort remains modest.

Priority follow-ups alongside the stages

  • GitHub profile: the profile README contains literal citation tokens and dated “right now” claims. Remove presentation artefacts, verify claims and align this important entrance with the independent-work identity.
  • Ontology downloads: Ontologies for projects contains 48 catalogue records. Its first sampled download, ontologies/2020BFOeasier.ttl, returned 404 at both the generated outside-repository URL and the expected repository-relative URL. Check publication layout as well as link construction; do not claim all 48 downloads were tested.
  • Preserve the useful atlas: /test/ is a substantive Project-Approach Atlas with eleven method entries, not one of the empty/placeholder roots. Salvage its premise, failure-mode and next-probe structure. Review its unsupported scores and outcome claims against current evidence before promotion or relocation.
  • Smaller entry repairs: make the innovation prototype’s actual app link clickable, and explain deliberately stripped framework repositories rather than promising missing toolkits.

Complete and review each stage before committing to the next. Discovery, explanation, model development and demonstrated human value are different advances; record which one a change actually achieves.