The application's own interface

Not undesigned — not ours to design. What this person can see and do in here is the application's decision, made by the application, against its own permission model.

Design note

This screen exists to make one boundary felt rather than stated. MOD One answered a single question to get the person here: may this person reach this application (FR-05). It has no further say. The portal tile, the tier, the device check and the eligibility group all stop at this line; the permission model on the other side is the application's own, and replacing it with one central role matrix is an explicit non-goal (§5.2).

The blank region below the header is the argument. It is the only screen here whose emptiness is deliberate and permanent — every other hole in this prototype is waiting for a decision. This one is waiting for nothing. Filling it with a plausible dashboard would suggest the platform has a view about what belongs inside an application, which is the erosion (§5.2) exists to prevent and the one this repository says grows "one convenient permission at a time".

It also replaced a false signal on the portal. Before this route existed, an eligible application with no mock behind it rendered as an inert tile — dimmed glyph, no arrow, no hover — which told a reviewer that an application a person is eligible for does not open. That was the prototype's scaffolding wearing a product signal. The inert treatment is gone with it.