I have read hundreds of program charters. The ones that work share a structure that the ones that don't lack. The difference is not format. It is specificity about the things that are hardest to get specific about before the work starts.
The first thing that belongs in a charter is the problem, not the solution. Most charters open with what the program will deliver. The ones that open with why it exists, and what breaks if it doesn't, are harder to write and far easier to use when priorities shift and scope gets contested.
Second is scope, stated in both directions. What is in scope and what is explicitly out of scope. The out-of-scope list is the more useful one. Things that are not listed as out of scope will be brought to the program at some point and will be harder to reject without the document.
Third is the definition of done. Not the milestone dates, the conditions under which the program is complete. What does success look like in measurable terms? What does the handoff look like? A program without a clear done condition does not end, it fades.
Fourth is the decision-making structure. Who can make what decisions without escalating, who needs to be consulted, and who needs to approve. That map prevents the two most common failure modes: decisions that never get made because nobody knows who owns them, and decisions that get unmade because the wrong person made them.
A charter written clearly enough to be held accountable to is a charter that will be used. One written loosely enough to be comfortable is a document that will be ignored when it matters.