Every statement in the report says where it comes from. What was seen is never mixed with what was assumed, and what was not tested is written as such.
→ /en/about
An auditor tired of doing it all by hand.
Marble Minotaur is built by one person, at siliceum, an engineering firm that makes the systems a business depends on reliable, fast and observable.
→ why
Why Marble Minotaur.
Whenever I am handed an application I do not know, the first days always look the same. I create an account, open every screen, look at headers, response times, forms, the phone, the console. I note what breaks, group what repeats, escalate what threatens. It is useful, it is slow, and it is exactly the same work from one client to the next.
Marble Minotaur does those first days in twenty minutes, and does them better on one point: it never forgets a screen. It gives me back the time to do what a tool cannot: understand why, and help with the fix.
I built it for my own engagements. I now offer it to teams who want that first look without waiting for a full engagement.
→ who
One person, ten years of audits.
Cédric Chariere Fiedler President and CTO Web and API architect: reliability, performance, QA Nantes
A web and API architect for more than ten years, I design and harden demanding platforms: quality, performance, maintainability.
Risk-driven testing, observability, load testing, resilience: the way Marble Minotaur looks at an application is the way I look at it on an engagement.
→ engagements
What I have done elsewhere.
siliceum engagements I worked on, where reliability and performance were measured, before and after.
Asobo Studio · Flight Simulator 2024 60 fps held on critical screens
Menus and cockpits are web UIs embedded in the engine: load times divided by 2 to 10, with no rewrite.
Euromaster −92% P99 latency
2.3 s brought down to 180 ms on the critical calls of a European B2B suite, migrated with no downtime across 5 countries.
B2B SaaS scale-up ÷6 support tickets a month
From 180 to 30 monthly tickets, by fixing recurring incidents one by one and tooling the team.
siliceum has worked for: Asobo Studio · Euromaster · Michelin · Arturia · CAE · Limagrain
→ method
Six rules, kept in every report.
An audit report commits its author: it tells people their work has defects. These rules are enforced by tests in the tool’s code.
Observed, inferred, not tested
Never a score out of 100
A score adds up things that do not add up, and invites people to push it up rather than fix things. The report says healthy, degraded, failed, incomplete or unknown.
Its failures are not yours
If the tool’s browser crashes or a guardrail stops it, that is written as its own limit, never blamed on the audited application.
A fact about the application is stated once
A defect on nearly every screen belongs to the foundation, not to each screen: one line, one fix.
No invented routes
A destination never observed is never drawn. When a language model names functions, anything it cites without having seen it is removed.
Written for those who built it
The report tells a team their work has defects. It says so plainly, with the evidence and the fix, and it also says what holds.
→ limits
What it cannot do, said up front.
- Black box
- What cannot be seen from a browser is not audited: the database, server code, infrastructure. That is a different audit, which siliceum also does.
- Unusual sign-in
- Login form detection is heuristic. Two-factor authentication or an unusual flow need some setup, sometimes a session prepared by hand.
- Noisy signals
- A few checks are sensitive to the technology used; they are flagged as such in the report and need a human review.
- Reading by a language model
- Optional and non-deterministic. It only names what was observed; it decides neither severity nor the health of a journey.
→ data
Your data, during and after.
- Staging preferred
- I recommend a staging environment and a dedicated test account with ordinary user rights.
- What a report contains
- HTTP headers, response excerpts and screenshots. It is handed to you; it is not meant for long-term storage.
- A light version
- To pass it around, a light version strips headers, responses and screenshots.
→ exit
It goes where the others stop.
The journey only starts on request. Send me three things, you receive the report.
- The address of the application, preferably a staging environment
- An account a test account with ordinary user rights
- The scope read only, or forms and clicks allowed
What happens next
- You send me the address and the scope. The test account comes separately, never in the email.
- I run it and read the report before sending it to you.
- We go through it together, half an hour on a call, so your team knows where to start.
The first runs are free, walk-through included, for teams willing to tell me afterwards what the report was missing.