Thank you for the detailed explanation 
I am building a UI with Phoenix LiveView and have never tried AshJsonApi and AshGraphql, so maybe that is where my confusion around public attributes comes from. If field policies only apply to public attributes, does that mean that field policies was initially intended for use in AshJsonApi and AshGraphql, and that it is less practical if I want to use it with LiveView?
I don’t think what I want is to hide private fields if I apply field policies. Then I would not even be able to use those fields, even for internal use. I think what I would have rather wanted, is for a way to include all fields (even private once) into field policies.
And if visibility of all fields would be covered by fields polices, that would also make the use of public attributes redundant, since the field polices would be deciding what should be visible to a user or not. I personally would prefer fields policies deciding what should be visible to a user or not, since that seems more explicit and give you more fine-grained control than a boolean. It also makes it a bit confusing having both the public field and field polices share the control of what should be visible or not. But that might be hard to change and don’t know if you agree.
field policies are only for reading. You prevent writes to attributes using regular policies.
Got to admit this one feels like a foot gun. My initial assumption was that field policies would cover both read and write. In the example case with a ticket system, both the admin and a regular user would normally be allowed to do writes to a ticket. But the regular user would normally be a bit more restricted and can only add follow up messages, while it should not be allowed to make changes to admin only information like an internal admin note. So would it be possible to make them also cover write operations?
