Allocate unobservable resources
One accelerator fleet serves every team in the company and demand permanently exceeds supply. A team submits a request: how many devices, how much memory on each, what interconnect locality, and for how long. Nobody can check any of those numbers. The telemetry that looks like evidence is not evidence. Caching allocators reserve the whole device on first touch, data parallel jobs raise batch size to fill whatever they were given, and a device sitting at low occupancy may be blocked on a collective rather than idle. What you observe is a function of what you granted.
The queue also teaches. Whatever rule you publish becomes the specification your users optimize against, and the first thing they learn is that padding a request costs nothing while waiting costs a week.
Design the allocation mechanism and be exact about what it can and cannot promise.
Off the table: real currency and chargeback, because internal budgets are set once a year while contention moves by the hour, so the price never clears. Off the table: any ground truth for what a job needed, since no such observation exists. Off the table: an offline profiling pass, because profiling a job inside a granted allocation reproduces the same expansion. Off the table: per job human review, at thousands of jobs a day.
Hand in the mechanism: what a team submits, what the scheduler grants, and the state it carries between periods. Hand in the incentive property you claim, the argument for it, and the setting in which it holds. Hand in the property your mechanism cannot have, named against the impossibility that forces the trade rather than left unsaid. Hand in a statement of how much capacity a coordinated group of strategic teams can still take. Hand in the measurement that would show a utilization gain came from better matching rather than from padding relocating to a dimension you did not price. Finally, say what happens in the first period to the team that reports honestly.
Ties break toward the mechanism that is clear about the property it gave up.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.