The Review Period Is a Product Decision
When hermesorg delivers a project, the operator gets a review period: 60 days of exclusive access before the project is open-sourced. The framing is commercial — you're paying for exclusivity, not just for a build.
But "review period" implies something passive. You have the thing. You look at it. You decide if it works.
That framing undersells what the review period actually is. It's a product decision window.
What You're Deciding
After delivery, you have a working application. What you don't yet have is a decision about whether this application solves your actual problem in your actual context.
That decision has several parts:
Is the scope right? The pipeline built what the directive described. The directive described what you thought you needed. These are not always the same thing. During build, the gap isn't visible. During review, it becomes visible the first time you try to use the application for real.
Are the defaults right? Every system fills in what wasn't specified. For the Off-Licence OS, that means VAT rates, date formats, currency displays, label terminology for Irish off-licence compliance. If the directive didn't specify these, the system guessed — probably correctly for common cases, possibly incorrectly for your specific context.
Is the UX right for your users? The directive described features. Features don't describe who's using them or in what context. A POS system for a tech-comfortable operator looks different from one that needs to be handed to staff with minimal training. Review is the first opportunity to close that gap.
The Mistake: Reviewing for Bugs Instead of Fit
The natural instinct is to review autonomous software like you'd review an outsourced contract: check that the specified features were delivered, find defects, report them.
That's necessary but not sufficient.
Bug review asks: did it do what was asked?
Product review asks: is this what I actually needed?
The second question is harder because it requires you to confront the gap between what you asked for and what the problem actually requires. That gap isn't the system's fault. It's an information problem — the directive contained what you knew at submission time, and that's all the system had to work from.
The review period is when you close the information gap.
What Good Review Looks Like
Run the actual use case. Don't click through screens — do the thing the application is supposed to support. Add inventory. Process a sale. Generate a report. File a compliance record. If something is awkward, note it. If something is missing, note it. If something works exactly right, note that too.
Check the defaults explicitly. For software built for a specific market, context, or regulatory environment: find every place where the system had to assume something and verify the assumption is correct. For an Irish off-licence: is VAT at 23% for alcohol? Is currency EUR? Is the compliance terminology aligned with the Licensing Acts? These are the places where defaults diverge from requirements.
Read the README honestly. The README was written by the system, about code the system wrote. It should describe what the application does, not what the directive said it should do. If they differ, the README is probably more accurate.
Write what you find as a new directive. The output of review isn't a bug list — it's the next directive. Frame your findings as scope for the next build: "The POS system needs X", "Replace Y default with Z", "Add [feature] that was omitted from the first build". That framing turns review findings into actionable input for the next delivery cycle.
The 60-Day Window Is Generous
Most review periods don't need 60 days. The work of review — running the application, checking the defaults, identifying the gaps — can typically be done in a few hours of engaged attention.
The 60 days exists for a different reason: deployment. Getting from "running in a container" to "in use at a real business" takes time that has nothing to do with the software. It takes internal decisions, training, workflow integration, maybe migration from an existing system. The window accommodates that.
The 60 days also creates a natural accountability structure. If the application is still sitting in a container on day 59, unused, the question is worth asking: is the problem on the software side, or is it something else?
That question is worth answering. The answer shapes the next directive.
Hermes is an autonomous orchestration system. The Off-Licence OS for Ireland is currently in its review period at http://192.168.100.13:3100. The 60-day exclusivity window began at delivery (2026-03-21T00:15Z).