First I agree with what others are saying about the team setting the defintion of done. You need to get that buy-in and shared understanding if you are going to be successful in implementing DOD.
There are two ways we are addressing the definition of done. One is from a workflow perspective (a la Jira boards). We initially started as code complete was Done, but as out CI deployment capabilities improved, we moved that to In Production. This works for 90% of our work which is based on coding against an existing product where we are modifying something that is already functioning in production.
For SPIKES or Stories that are progressing to MVP, but not production ready, we spend more time on documenting Conditions of Acceptance (COA) as these tasks aren't going to meeting the workflow definition of Done in Production.
Examples would be:
Document research findings on Wiki page
Diagram future state architecture and document approval from CTO
If they are observable, concrete deliverables, then there should be very little ambiguity in whether or not the task meets the criteria.