The Portal Looks Ready In The Demo
Consider an illustrative service company reviewing a new customer portal. A customer signs in, opens a work order, downloads the attached report, and requests an update. The pages look polished, and the demonstration is convincing.
The business has seen one customer use one record. It has not yet seen what happens when a different customer requests that record or attachment. Nor has it checked what happens after a user's access is removed. Those questions are part of the product's behavior even though they are easy to leave out of a presentation.
I would include customer separation in the acceptance conversation from the start. The business should be able to say who may see and change each kind of record, then ask for evidence that the application respects those rules. A finished screen is useful, but it is only one visible part of a working portal.
A Login Does Not Describe Every Permission
Signing in establishes an identity. It does not by itself establish which customer records that identity may access. OWASP's Authorization Cheat Sheet distinguishes those concepts and recommends checking permission for each request, with access denied when no permitted rule applies.
For the proposed portal, the business must decide what that means in ordinary operating terms. A customer contact might be allowed to see work orders for one location. A regional contact might cover several locations. A former contact might retain no access. Staff may have a different scope again.
Write down those cases before asking a builder to choose a rule. Otherwise the implementation may reflect an assumption nobody approved. The important output is a small, understandable mapping between people, records, and allowed actions. It gives the business and the builder something specific to review together instead of relying on a general statement that the portal is secure.
Treat Verification As Part Of The Build
Here is a hypothetical planning example. Suppose an acceptance review requires two hours to agree on the customer cases, three hours to prepare and run them, and one hour to review the evidence. That is six staff hours devoted to this boundary.
If a later correction takes another four hours, those hours belong in the actual cost of preparing the feature. Do not hide them because AI generated the first version quickly. Equally, do not claim the six-hour review prevents a particular financial loss. The test gives evidence about defined behavior under tested conditions, not a guarantee about every future incident.
The business can measure time spent clarifying rules, correcting defects, and repeating checks after relevant changes. That information supports realistic delivery planning. Faster code generation may release capacity, but the accepted outcome includes the verification needed to make the feature suitable for its intended use.
Our Proposed SynHy Approach
We could build and review the portal around an explicit customer-access agreement. The application would apply the approved rules to records and their supporting files, and the release review would include both permitted and denied cases.
AI could assist the builder with implementation and preparation of test cases. Ordinary application logic would enforce access decisions. A responsible technical reviewer would inspect that behavior, and the business owner would resolve ambiguities about who should have access. A model's own description of its work would not replace those reviews.
The first scope could be one record type, such as a service work order, and its report attachment. That is narrow enough to inspect thoroughly. The design should also provide a clear customer-facing response when an action is unavailable, without exposing another customer's details in the explanation. The result would be a usable feature supported by evidence about its defined boundary.
Use Two Customers And An Approved Test Record
Review The Places Where A Rule Can Drift
The business rule should remain consistent wherever the work order appears. A search result, detail page, attachment, notification, and update action may each involve the same underlying customer relationship. The reviewer needs to understand which of those surfaces the release includes.
That does not mean collecting every conceivable test before building a small feature. It means accounting for the actual ways the feature exposes its records. A customer boundary that works on the main page but is absent from a download does not fulfill the intended agreement.
Include ordinary changes in the review: a contact moves to another location, a staff member changes responsibility, or access is removed. The team should decide when those changes take effect and what existing sessions may do afterward. Where the operating rule is unclear, record the question and have the responsible person answer it before the implementation turns an assumption into customer-visible behavior.
| Current Illustrative Pattern | Proposed Pattern |
|---|---|
| A signed-in demo looks complete | Two separate customer accounts prove the boundary |
| A hidden button implies a blocked action | The underlying request must enforce the same rule |
| One passing example supports a broad claim | Acceptance names the release and cases actually tested |
Give A Failed Check A Release Decision
Unexpected access should stop acceptance of the affected feature. The technical owner needs the specific test case, observed result, and relevant release version. The business owner needs to understand which intended boundary failed and what work can safely continue while it is corrected.
If the issue is an unclear business rule, resolve that first. If the rule is clear but the implementation is wrong, correct and retest it. These are different problems, and changing the test to match the current code is not a substitute for either decision.
The team should preserve the failed case so a later change can be checked against it. The release note should distinguish corrected behavior from unresolved limitations. A single passing check after a repair does not justify claiming that every part of the application has been reviewed. Acceptance should name the feature, its intended users, and the evidence actually available.
Measure More Than Passing Tests
Record whether legitimate customer actions work as well as whether prohibited ones are refused. A portal that prevents everyone from opening any record would satisfy neither the business need nor the intended access design.
Track unresolved permission decisions, defects found during review, and the effort required to correct them. Keep the tested release and cases identifiable so the evidence remains useful after the next change. When a feature or customer relationship changes, review which checks need updating.
The scorecard is an aid to release judgment, not a security certification. It should show what the team knows and what remains outside the tested scope. The business can then make a proportionate decision about this feature while arranging any broader review its system requires. That is a more useful conversation than comparing how many screens were generated or how quickly the first demonstration became available.
| Measure | Purpose |
|---|---|
| Allowed actions completed correctly | Checks that legitimate work still functions |
| Denied cases with no record exposure | Tests the intended customer boundary |
| Unresolved permission decisions | Shows what the business has not agreed |
| Review and correction effort | Includes the work behind a dependable release |
Start With The Boundary That Matters To This Feature
For a first portal release, gather a few representative customer relationships, sample records, intended actions, and the people authorized to decide the rules. Use approved test information rather than unnecessary live customer data. Include someone who understands how customer access changes during normal operations.
The first build could cover viewing one work-order type and its attachment, with a clear acceptance record for that scope. It does not need every future portal feature to establish a useful customer boundary.
Ask the builder to explain the permitted and denied cases in terms the business can understand. Ask the reviewer to show the observed results. If the explanation depends entirely on how the screen looks, the review is unfinished. Expand only after the team can demonstrate the intended behavior and knows how to maintain it when the feature or customer relationships change.
Make Built Well A Reviewable Statement
Software quality becomes easier to discuss when a broad claim turns into a concrete question. Can this customer use the intended record? Can another customer be kept out of it? What evidence supports the answer for the release being delivered?
SynHy could help define and verify that boundary for a focused customer portal. Bring the record type, the people who need it, and the actions each person should be allowed to take.
The intended outcome would be a small working feature with an understandable acceptance record. AI could accelerate implementation, while the business and technical owners retain responsibility for the rules and the evidence behind the release. That makes the distinction between generating software and delivering dependable behavior something the team can actually inspect.