diff --git a/charter.adoc b/charter.adoc
index a25c7d2..e0dd6a6 100644
--- a/charter.adoc
+++ b/charter.adoc
@@ -2,8 +2,8 @@
 
 The RISC-V hardware performance monitoring counters (Zihpm) provide support for counting programmable performance events.  Such events can provide insights into software execution behavior, insights that are critical when tuning a profiled workload.  However, no performance events are standardized, which means profiling tools must comprehend a custom set of events specific to each hardware implementation.  This prevents profiling tools from offering general-purpose, event-based analysis capabilities that can be employed regardless of the underlying hardware implementation.
 
-The Performance Events TG will develop a non-ISA extension that includes a set of standard performance events and metrics (or formulas of events). For each standard event, the name and the precise hardware behavior associated with it will be specified, though the event selector value associated with the event will be left up to implementations. For each standard metric, the name, precise description and event formula, including the names of the constituent events, will be defined.
+The Performance Events TG will develop a non-ISA extension that includes a set of standard performance events and metrics (or formulas of events). For each standard event, the name and the precise hardware behavior associated with it will be specified, though the event selector value associated with the event will be left up to implementations. For each standard metric, the name, precise description, and event formula, including the names of the constituent events, will be defined.
 
-There could be cases when a microarchitecture decide to not implement a performance event in hardware and provide a metric for it instead. Also from the profiling tools users point of view distinction between events and metrics looks not important – e.g. for them everything can be a metrics whether it is implemented as complex formula or mapped directly to a hardware event. The group will consider such working model and may suggest some improvements for the Linux perf to support it.
+There could be cases when a microarchitecture decide to not implement a performance event in hardware and provide a metric for it instead. Also from the profiling tools users point of view distinction between events and metrics looks not important – e.g. for them everything can be a metrics whether it is implemented as complex formula or mapped directly to a hardware event. The group will further consider whether some standard events may themselves be counted using event formulas rather than direct hardware events, and what tool improvements may be needed to support such implementations.
 
-The TG will further prototype the end-to-end solution using Linux perf and QEMU, ensuring that perf can properly translate event and metric names.
+The TG will consider whether RISC-V-specific changes are needed to standard JSON file formats used by tools to map event names to event selector encodings, and to map metric names to event formulas. The TG will further prototype the end-to-end solution using Linux perf and QEMU, ensuring that perf can properly translate event and metric names.