My organization has been leveraging SAFe for a few years now and as a Team lead I am concerned about the sort of Feature Acceptance Criteria being defined. Specifically its extremely vague and I would hope that SAFe or even Agile would have some guidelines around 'good' AC on a feature.  

I see the SMART acronym thrown around a lot ( Specific, Measurable, Achievable, Realistic, and Timely) and that's an example of a guideline I was thinking of.

By way of example, my current feature has an AC: 'Verify the put API updates correct information in DB'
Imho that's too loosely defined (what is 'correct'?) to be valuable to us.

since terminology may be slightly different: the 'feature' I am referring too is the work that a dev team gets assigned at the Quarterly planning where the team tries to break it down into stories.

Somewhat related: if a dev team encounters a scenario during Increment Planning where it is not comfortable that the feature is fully understood, what are the recommended ways to raise those concerns? We have been raising Risks thus far but since those get 'accepted' its not really leading to meaningful improvement in the feature definition process.

Any SAFe experts want to guide me? thanks