Practices (for example review routines, test strategies, demo rhythm) change and get tuned over time. Values and principles do not. Or if they do, it is a major event, worth noticing. Capturing them explicitly gives a shared root system that later practices can grow out of. When a practice and a value end up in conflict, the value wins. If it comes out the other way around, something is wrong.
Here you describe the values and principles that are active and agreed for this initiative. For large initiatives descriptions per team may sometimes be needed, but that is not the common case.
Just as the intent description in the Strategy briefing guides all the micro-decisions of everyday work, so do values and principles.
Practices are typically described on the Teams tab, but nothing stops you from adding relevant information here too, if it serves a purpose.
As inspiration, here is what Kent Beck formulated about values and principles in Extreme Programming Explained:
Values
Communication: keep everyone informed. Problems can usually be traced back to someone not knowing something they should have been told.
Simplicity: do the simplest thing that could possibly work. Remove what is not needed.
Feedback: short, frequent feedback loops at every level (test, build, demo, customer, money).
Courage: tell the truth, throw away code that is wrong, redo when needed.
Respect: respect for the work, the team and the users. The foundation the other four values rest on.
Principles
Humanity: software is built by people. Balance personal and collective needs.
Economics: make sure what we do has business value. Defer decisions to the point where they actually matter.
Mutual Benefit: every change should benefit everyone involved, both now and later.
Self-Similarity: use the same shape of solution at different scales.
Improvement: excellence is an aspiration and a process. Deliver something good, then make it better.
Diversity: bring different perspectives, skills and opinions to the table.
Reflection: combine reflection on the work with the work itself.
Flow: deliver a steady stream of small valuable steps, rather than big batches.
Opportunity: treat problems as opportunities to learn.
Redundancy: solve critical, difficult problems in several different ways.
Failure: when you do not know what to do, try something. Failure is information.
Quality: quality is not a control variable. Do not sacrifice quality for speed, you will not get it back later.
Baby Steps: the smallest step that could possibly work, taken now.
Accepted Responsibility: responsibility follows authority. Assign it, do not impose it.
Further reading
Beck, K. Extreme Programming Explained: Embrace Change (2001)