What parts of clean architecture are valuable in a .NET API, and how would you avoid turning it into ceremony?

In production I protect dependency direction with project references or architecture tests, but I also watch runtime concerns that diagrams omit. Transactions, authorization, telemetry, retries, and idempotency need explicit ownership across boundaries. Mapping has a cost, so I avoid duplicate models that add no protection. I evolve the structure from observed coupling: extract a boundary when vendor types leak, business tests require infrastructure, or unrelated changes collide repeatedly. A useful architecture allows a developer to locate a rule, understand one request, and replace an adapter without rewriting policy.