Update charter.adoc

Call out discoverability requirements, per TSC review

Signed-off-by: Beeman Strong <97133824+bcstrongx@users.noreply.github.com>

charter.adoc

@@ -9,7 +9,7 @@ The Performance Event Sampling TG aims to fill these gaps by defining two new IS
 * An extension that enables precise attribution of samples based on select events (e.g., instruction/uop retirement events) to the instruction that caused the counter overflow, despite implementations where the associated sampling interrupt may skid. This will provide more directly actionable information to the user, by precisely identifying the instructions that are most often experiencing performance events.
 * An extension that enables sampling of instructions and/or uops, with collection of runtime metadata for the instruction/uop, including data virtual address, select event occurrences, and latencies incurred. Such samples can be filtered based on instruction/uop type, events incurred, or latencies observed, allowing the user to focus on samples of interest. Further, associated sampling interrupts can be skidless, allowing the user to collect additional sample state (call-stack, register values) reliably.
 
-Each extension will be crafted to be implementation-friendly even for high-performance, out-of-order microarchitectures, such that an implementation that incurs no performance overhead beyond that resulting from the handling of sampling interrupts can be acheived with reasonable hardware cost and complexity. The extensions will be compatible with the H extension, and support RISC-V security objectives.
+Each extension will be crafted to be implementation-friendly even for high-performance, out-of-order microarchitectures, such that an implementation that incurs minimal to no performance overhead beyond that resulting from the handling of sampling interrupts can be acheived with reasonable hardware cost and complexity. The extensions will be compatible with the H extension, and support RISC-V security objectives. The extensions will additionally specify which aspects must be discoverable, and work with the appropriate groups (PRS TG, UD) to define the mechanism.
 
 The TG will prototype support for the new extensions in Qemu and Linux perf, to demonstrate the usability of the ISA for kernels and tools.