Open documentation · source code · exact versions

Open source code and technical evidence

This collection presents public projects that demonstrate code, architecture, working methods and documented boundaries. Every primary project links to an exact commit, making the referenced version explicit.

By Finn Andre Hotvedt. Published and last checked 24 September 2026. This is owner-published documentation, not an independent certification.

Publication review · 24 September 2026

Three projects with reviewed public history

Before publication, all advertised branches, tags, LFS objects, Git objects, commits and available history were reviewed for secrets, customer information, personal data, private infrastructure and unsuitable binary files. The review covers what the repository advertised to the client clone; it cannot prove the contents of unadvertised server-internal objects.

MIT · design foundation

Resilient Embedded House-Control Foundry

A documented meta-foundation for resilient home control using CAN, distributed ESP32 nodes, optional service layers and reusable architecture and validation templates.

Dated history: earliest reviewed commit 11 March 2026.

Evidence boundary: method, design and architecture—not completed firmware or a physically verified installation.

Open reviewed commit 20d9c3f

MIT · local prototype

Universal Meta-Foundry

A prompt-governed workflow that makes project creation repeatable through intent, metaprompts, task lifecycle, template governance and documented reuse.

Dated history: earliest reviewed commit 12 March 2026.

Evidence boundary: a local prototype with synthetic example material—not a customer delivery or validated production operation.

Open reviewed commit 69ed5a0

Public code · current-state review

More open code examples

These repositories are public and received a README/current-tree review on 24 September 2026. They did not receive the same new complete-history review as the three projects above.

The principle behind the evidence

Open methods. Verifiable evidence. Protected people.

Why

Both the beauty and the chaos must be understood

I saw early both the beauty and the chaos that artificial intelligence could create. That is why I began testing not only what works, but also what can go wrong.

Transparency

The method and controls should be open to inspection

I want full transparency about our methods, controls and evidence. It is like displaying the calculator in the office: anyone can inspect the tool and understand how it is used without gaining access to the customer’s calculation.

The boundary

Transparency must never expose people

Customers, relationships, credentials and private information must be protected without compromise. Transparency does not mean exposing people. It means making power accountable.

We show the calculator – not the customer’s calculation. Great technological power carries even greater responsibility.

Owner-published verification packages

Documented system evidence

These public GitLab repositories show bounded tests, contracts and evidence boundaries for systems built or checked by Finnandre. They are owner-published documentation and must not be described as independent audits.

Read it correctly

What this collection proves—and what it does not

Documented

Authorship, public source and a specific version

The repository and commit links let another person inspect the exact code and documentation referenced by each description.

Bounded

Architecture, prototype or method

The maturity level is stated for each project. An architecture document is not automatically completed firmware, and a prototype is not automatically production-approved.

Not claimed

No ranking, AI uplift, priority or independent certification

Public source may make the work easier to discover and verify, but it does not prove improved Google ranking, AI citation, customer results or that an idea was first in the world.

Open means explicit terms

Read, learn and reuse within the license

The MIT and Apache-2.0 projects may be reused under the terms in each repository. Retain required copyright and license notices, and always check the repository’s own LICENSE file before distribution.

This page is an entry point to public material. Private customer projects, proprietary products, secrets and uncleared repositories are deliberately excluded.

Explore more free guides in Finnandre Open