Align website claims and project hierarchy with public repository evidence

[projectious]

Finding

The website is the public presentation layer, but its README and GitHub description do not state a maturity/support classification. More importantly, the live site’s service and project claims can easily become stronger than the evidence in evolving repositories.

The accepted portfolio hierarchy is:

1. aibox and processkit as primary technical anchors;
2. ai-market-research as applied decision-support evidence;
3. kubeclaw as an explicit prototype/learning narrative;
4. Kaits only after stronger reproducible proof;
5. brand and website as supporting assets;
6. ainfra-templates omitted from promotion while implementation is only starting.

Evidence inspected 2026-07-26:

• website README and GitHub description
• current public repository READMEs and maturity signals
• closed website baseline issue Portfolio standards baseline #1

Proposed change

• Label this repository Supporting asset — maintained.
• Audit every site claim about services, products, security, maturity, clients, scale, and project capabilities against current public evidence.
• Add a project/ecosystem presentation that uses the shared maturity vocabulary and links directly to each project’s proof and limitations.
• Present Bernhard Gerlach’s operations, transformation, and technical-program experience as the through-line; describe software repositories as evidence of translating operating models into technical mechanisms.
• Keep KubeClaw visibly prototype-labelled; do not feature Kaits or ainfra-templates as substantive offerings until their own evidence gates are met.
• Add a documented content-review checklist and dated evidence-source map for future updates.
• Keep company positioning and Bernhard’s personal/LinkedIn identity related but distinct.

Acceptance criteria

• README identifies the website as a supporting public interface and documents local validation/deployment.
• Every material public claim maps to a current source, project artifact, or explicit owner-approved statement.
• Project cards/pages show accurate maturity and limitations without relying on badges alone.
• Portfolio hierarchy and common narrative are understandable within two minutes.
• Prototype/research projects are not presented as client-ready products.
• Site content contains no fabricated clients, adoption, metrics, certifications, or assurance claims.
• Accessibility, link, and local production-export checks pass; no GitHub Actions are added.

Legal, privacy, and security

Maintain asset provenance and privacy/data-handling requirements from closed issue #1. Personal and consulting claims require Bernhard’s explicit review.

Ownership and dependencies

Owned by website. Coordinate visual vocabulary with brand and factual maturity with each project’s README; repository evidence wins when descriptions conflict.