diff --git a/mkdocs.yml b/mkdocs.yml
index 28ba5d5b5a..a32b0c0bd8 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -24,6 +24,7 @@ nav:
           - Near-Infrared Spectroscopy: modality-specific-files/near-infrared-spectroscopy.md
           - Motion: modality-specific-files/motion.md
           - Magnetic Resonance Spectroscopy: modality-specific-files/magnetic-resonance-spectroscopy.md
+          - Electromyography: modality-specific-files/electromyography.md
       - Derivatives:
           - BIDS Derivatives: derivatives/introduction.md
           - Common data types and metadata: derivatives/common-data-types.md
diff --git a/src/introduction.md b/src/introduction.md
index 2a5a377fe7..84e4ceea7c 100644
--- a/src/introduction.md
+++ b/src/introduction.md
@@ -192,6 +192,10 @@ For example:
     Scientific Data 12, (13841).
     [doi:10.1038/s41597-025-05543-2](https://doi.org/10.1038/s41597-025-05543-2)
 
+#### EMG
+
+-   (publication forthcoming)
+
 ### Research Resource Identifier (RRID)
 
 BIDS has also a
diff --git a/src/modality-specific-files/electromyography.md b/src/modality-specific-files/electromyography.md
new file mode 100644
index 0000000000..5debdcb366
--- /dev/null
+++ b/src/modality-specific-files/electromyography.md
@@ -0,0 +1,703 @@
+# Electromyography
+
+Support for Electromyography (EMG) was developed as a
+[BIDS Extension Proposal](../extensions.md#bids-extension-proposals).
+Please see [Citing BIDS](../introduction.md#citing-bids) on how to appropriately credit
+this extension when referring to it in the context of the academic literature.
+
+!!! example "Example datasets"
+
+    Electromyography datasets formatted according to this specification are available on
+    the [BIDS examples repository](https://github.com/bids-standard/bids-examples#emg)
+    and can be emulated when curating new datasets.
+
+## EMG data
+
+{{ MACROS___make_filename_template(
+"raw",
+datatypes=["emg"],
+suffixes=["emg", "events"])
+}}
+
+EMG device manufacturers use a variety of formats for storing raw data, and there is
+no single standard that all researchers agree on. For BIDS, EMG data MUST be
+stored in one of the following formats:
+
+| **Format**                                                         | **Extension(s)**         | **Description**                                                                                                                                                                                      |
+| ------------------------------------------------------------------ | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Biosemi data format](https://www.biosemi.com/faq/file_format.htm) | `.bdf`                   | Each recording consists of a single `.bdf` file. [`bdf+`](https://www.teuniz.net/edfbrowser/bdfplus%20format%20description.html) files are permitted. The capital `.BDF` extension MUST NOT be used. |
+| [European data format](https://www.edfplus.info/)                  | `.edf`                   | Each recording consists of a single `.edf` file. [`edf+`](https://www.edfplus.info/specs/edfplus.html) files are permitted. The capital `.EDF` extension MUST NOT be used.                           |
+
+EDF, EDF+, BDF, and BDF+ are all open data formats with broad support in various programming languages for reading and writing the files. BDF and BDF+ formats store data samples using 3 bytes instead of 2 bytes as in EDF and EDF+ formats, allowing for greater resolution. EDF+/BDF+ accommodate more header metadata than EDF/BDF, and support storing event or annotation information in the file. Thus it is RECOMMENDED to use the BDF+ data format.
+
+The [`recording-<label>`](../appendices/entities.md#recording) entity MAY be used to indicate
+simultaneous acquisition of data from multiple EMG devices, in cases where the devices
+store data in separate data files.
+If separate devices are being used with separate sampling rates, start times, or other
+acquisition parameters, the `recording-<label>` entity MUST be used to distinguish between them.
+The synchronization of data from multiple devices SHOULD be described in the
+[Scans](../modality-agnostic-files/data-summary-files.md#scans-file) (`scans.tsv`) file, using the
+`acq_time` entity.
+
+In cases where the allowed formats do not encode all relevant metadata present in the
+device manufacturer's native file format, we encourage users to provide the additional
+metadata in the sidecar JSON file.
+
+### Terminology: Electrodes vs. Channels
+
+For proper documentation of EMG recording metadata it is important to understand the
+difference between an electrode and a channel: an EMG electrode is a single point of
+electrical contact with the body, whereas a channel is the combination of the analog
+differential amplifier (which combines signals from two electrode sources) and the
+analog-to-digital converter, which results in a potential difference (voltage) that forms
+the actual data stored in the EMG dataset. We employ the following short definitions:
+
+-   **Electrode:** A single point of contact between the acquisition system and
+    the recording site (whether on the skin surface or intramuscular).
+    Multiple electrodes can be organized as arrays, grids, leads, strips, probes,
+    shafts, and so on.
+
+-   **Channel:** A single analog-to-digital converter in the recording system that
+    regularly samples the value of a transducer, which results in the signal being
+    represented as a time series in the digitized data.
+    This can be connected to two electrodes (to measure the potential difference between
+    them), a magnetic field or magnetic gradient sensor, temperature sensor,
+    accelerometer, and so forth.
+
+This distinction is especially important for EMG because a common type of EMG device
+(often erroneously called a "bipolar electrode") comprises two electrodes at a fixed distance,
+wired such that the electrode pair is necessarily converted to a single channel by the amplifier
+(in other words, one of the electrodes necessarily acts as the _reference_ for the other).
+In other kinds of devices, researchers may have control over which electrode(s) to use as
+the reference for each channel.
+
+Note also that although the _reference_ and _ground_ electrodes are often referred to as
+channels, in most common EMG systems they are not recorded by themselves.
+Therefore they are usually not represented as channels in the data.
+<!-- The type of referencing for all channels and optionally the location of the reference
+electrode and the location of the ground electrode MAY be specified. -->
+
+### Describing sensor locations
+
+Each EMG-BIDS dataset SHOULD include sensor location information that is as accurate as
+possible given the measurement means available to the researcher(s).
+Below are examples ranging from most accurate to least accurate, which can serve as a
+guide to where sensor placement information should be stored in the dataset.
+
+1.  Electrode locations and anatomical landmarks are digitized with a 3D localizer device
+    such as Polhemus FasTrak or a 3D scanner.
+    3D coordinates for each electrode are given in `x,y,z` columns of `*_electrodes.tsv`,
+    and the coordinate system definition is given in `*_coordsystem.json`.
+
+1.  Electrode locations are measured relative to nearby anatomical landmarks using a flexible
+    measuring tape.
+    2D or 3D coordinates for each electrode are given in `x`, `y`, and (optionally) `z`
+    columns of `*_electrodes.tsv`, and the coordinate system definition in
+    `*_coordsystem.json` specifies the axis directions with reference to those anatomical
+    landmarks.
+
+1.  The arrangement of electrodes in a group or grid is measured (or known from the device
+    manufacturer), and is provided in `x`, `y`, and (optionally) `z` columns of `*_electrodes.tsv`,
+    with a device-internal "child" coordinate system defined in a `*_coordsystem.json` file.
+    An anatomically-defined "parent" coordinate system is also defined in a different
+    `*_coordsystem.json` file, and the name and coordinates of one electrode (the "anchor"
+    electrode) from each "child" group or grid is provided in the "parent" coordinate system.
+    This allows the approximate anatomical locations of all electrodes to be calculated
+    by treating the device-internal coordinates as offsets from the anchor coordinate.
+    The two `*_coordsystem.json` files are distinguished by the `space` entity in their filenames;
+    the labels used for that entity may be arbitrary (for example, `*_space-grid_coordsystem.json`
+    for the child coordinate system, and `*_space-forearm_coordsystem.json` for the parent
+    coordinate system).
+
+1.  Individual electrode locations are chosen by visual inspection, palpation, or
+    functional localizers.
+    No measured coordinates are provided; placement information is given either in the
+    `EMGPlacementSchemeDescription` field of `*_emg.json` (when the placement approach is
+    the same for all sensors), or in the `placement_description` column of `*_channels.tsv`
+    (when the placement approach varied across sensors).
+
+More details on each of these scenarios is given below in the
+[Channels description](#channels-description-_channelstsv),
+[Electrodes description](#electrodes-description-_electrodestsv), and
+[Coordinate system](#coordinate-system-json-_coordsystemjson) sections.
+
+A fifth scenario unique to EMG involves location information that is fairly accurate
+(as in scenarios (1) and (2) above) but it locates _bipolar sensor devices_ rather than
+_electrodes_.
+In this case, researchers SHOULD provide `*_electrodes.tsv` even though information about
+the individual electrode contacts is not available.
+Rather, each entry from `*_channels.tsv` should have a corresponding row in `*_electrodes.tsv`
+where the location information is given, and `*_coordsystem.json` should also be provided
+(as in scenarios (1) or (2) above).
+
+### EMG in combination with other modalities
+
+When EMG is recorded alongside other BIDS modalities (such as EEG or motion),
+researchers SHOULD define how recordings are synchronized. Options include:
+
+-   Recording time stamps from a common clock source on the LATENCY channel of
+    each modality’s acquisition device.
+
+-   Recording experimental events (usually as TTL pulses) on dedicated channels of
+    each modality’s acquisition devices.
+
+-   Storing the acquisition time (relative to a common clock source) of the first data point
+    of each modality’s recording in the acq_time column of the *_scans.tsv file.
+    Note that the BIDS date time format allows optional fractional seconds,
+    which SHOULD be used to maximize the precision of the synchronization.
+
+-   Record the start- and stop-time of one modality’s recording (relative to
+    the other modality’s clock) in the *_events.tsv file for the other modality.
+
+It is up to the user to decide which approach is most appropriate given their experimental setup,
+and to identify which modality will serve as the 'main' clock source for synchronization purposes
+(or whether a separate external clock source is used).
+
+### Sidecar JSON (`*_emg.json`)
+
+For consistency between studies and institutions,
+we encourage users to extract the values of metadata fields from the actual raw data.
+Whenever possible, please avoid using ad hoc wording.
+
+These fields MUST be present:
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGRequired") }}
+
+These fields SHOULD be present:
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGRecommended") }}
+
+Note the `RecordingType`, which depends on whether the data stream on disk is interrupted or not.
+Continuous data is by definition 1 segment without interruption.
+Epoched data consists of multiple segments that all have the same length
+(for example, corresponding to trials) and that have gaps in between.
+Discontinuous data consists of multiple segments of different length,
+for example due to a pause in the acquisition.
+
+These fields MAY be present:
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGOptional") }}
+
+Note that the date and time information SHOULD be stored in the study key file
+([`scans.tsv`](../modality-agnostic-files/data-summary-files.md#scans-file)).
+Date time information MUST be expressed as indicated in [Units](../common-principles.md#units).
+
+#### Hardware information
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGHardware") }}
+
+#### Task information
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGTaskInformation") }}
+
+Note that the `TaskName` field does not have to be a "behavioral task" that subjects perform,
+but can reflect some information about the conditions present when the data was acquired
+(for example, `"treatment"`, `"control"`, or `"sleep"`).
+
+#### Institution information
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_sidecar_table("emg.EMGInstitutionInformation") }}
+
+#### Example `*_emg.json`
+
+<!-- TODO do we need separate ElectrodeManufacturer and Manufacturer fields like iEEG? -->
+<!-- TODO check if hardware filters are plausible for an EMG system -->
+```JSON
+{
+  "EMGChannelCount":4,
+  "EMGGround":"n/a",
+  "EMGPlacementScheme":"Other",
+  "EMGPlacementSchemeDescription":"midpoint between cubital fossa and radial styloid process",
+  "EMGReference":"4 reference electrodes built-in to device, placed near the midpoint between radial and ulnar styloid processes on the volar surface",
+  "HardwareFilters":{"Highpass RC filter": {"Half amplitude cutoff (Hz)": 0.0159, "Roll-off": "6dBOctave"}},
+  "InstitutionAddress":"9500 Gilman Drive 0559, La Jolla, CA 92093",
+  "InstitutionalDepartmentName":"Swartz Center for Computational Neuroscience",
+  "InstitutionName":"University of California San Diego",
+  "Instructions":"Jump straight upward as high as you can, while keeping your arms at your sides.",
+  "Manufacturer":"Delsys",
+  "ManufacturersModelName":"Trigno® Galileo",
+  "PowerLineFrequency":60,
+  "RecordingDuration":123.456,
+  "RecordingType":"continuous",
+  "SamplingFrequency":1000,
+  "SoftwareFilters":"n/a",
+  "TaskDescription":"jumping with stationary arms",
+  "TaskName":"jumping"
+}
+```
+
+## Channels description (`*_channels.tsv`)
+
+<!--
+This block generates a filename templates.
+The inputs for this macro can be found in the directory
+  src/schema/rules/files/raw
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filename_template("raw", datatypes=["emg"], suffixes=["channels"]) }}
+
+A channel is represented by one time series recorded with the recording system.
+Although this information can often be extracted from the EMG recording,
+listing it in a simple `.tsv` document makes it easy to browse or search
+(for example, searching for recordings with a sampling frequency of >=1000 Hz).
+Hence, the `*_channels.tsv` file is RECOMMENDED.
+Channels SHOULD appear in the table in the same order they do in the EMG data file.
+Additional columns MAY be included to provide additional information about the channels.
+Note that electrode positions SHOULD NOT be added to this file but to `*_electrodes.tsv`.
+
+The columns of the channels description table stored in `*_channels.tsv` are:
+
+<!-- This block generates a columns table.
+The definitions of these fields can be found in
+  src/schema/rules/tabular_data/*.yaml
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_columns_table("emg.EMGChannels") }}
+
+Restricted keyword list for field type in alphabetic order (shared with the MEG
+and EEG modality; however, only types that are common in EMG data are listed here).
+Note that upper-case is REQUIRED:
+
+| **Keyword** | **Description**                                                                                                                                                                                                                                                                   |
+| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| VEOG        | Vertical EOG (electrooculogram)                                                                                                                                                                                                                                                   |
+| HEOG        | Horizontal EOG                                                                                                                                                                                                                                                                    |
+| EOG         | Generic EOG channel if HEOG or VEOG information not available                                                                                                                                                                                                                     |
+| ECG         | ElectroCardioGram (heart)                                                                                                                                                                                                                                                         |
+| EMG         | ElectroMyoGram (muscle)                                                                                                                                                                                                                                                           |
+| TRIG        | Analog (TTL in Volt) or digital (binary TTL) trigger channel                                                                                                                                                                                                                      |
+| MISC        | Miscellaneous                                                                                                                                                                                                                                                                     |
+| SYSCLOCK    | Elapsed time since trial/recording start, as provided by the recording device.                                                                                                                                                                                                    |
+| LATENCY     | Latency of sample, in seconds from recording onset, typically from an _external_ clock source. See `acq_time` column of the respective `*_scans.tsv` file. MUST be in form of `s[.000000]`, where `s` reflects whole seconds, and `.000000` reflects OPTIONAL fractional seconds. |
+| REF         | Reference channel                                                                                                                                                                                                                                                                 |
+
+Examples of common free-form text for the `description` column (these should occur _without enclosing quotation marks_):
+
+-   n/a
+-   stimulus
+-   response
+-   skin conductance
+-   battery status
+
+### Example `*_channels.tsv`
+
+See also the corresponding [`electrodes.tsv` example](#example-electrodestsv).
+```Text
+name  type  units  signal_electrode  reference  target_muscle
+emg1  EMG   V      E1                E2         anterior belly of the digastric
+emg2  EMG   V      E3                E4         levator angulis oris, zygomaticus major
+emg3  EMG   V      E5                E6         platysma
+emg4  EMG   V      E7                E8         obicularis oris
+```
+
+## Electrodes description (`*_electrodes.tsv`)
+
+<!--
+This block generates a filename templates.
+The inputs for this macro can be found in the directory
+  src/schema/rules/files/raw
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filename_template("raw", datatypes=["emg"], suffixes=["electrodes"]) }}
+
+File that gives the measured location, size, and other properties of EMG electrodes.
+If an `*_electrodes.tsv` file is specified, a `*_coordsystem.json` file MUST be specified
+as well.
+
+Electrode locations may be specified in one of four ways:
+
+1.  **Coordinates and landmarks digitized in situ.**
+    When 3D electrode locations are digitized in situ, the origin, orientation, and measurement
+    unit of the coordinate system MUST be recorded in Cartesian coordinates according to the
+    `EMGCoordinateSystem` and `EMGCoordinateUnits` fields in `*_coordsystem.json`,
+    as described in the [Coordinate Systems Appendix](../appendices/coordinate-systems.md).
+    In such cases, `EMGCoordinateSystem` SHOULD be specified as `Other`, the
+    `EMGCoordinateSystemDescription` SHOULD contain a description of the origin and axis
+    orientations of the 3D coordinate system, and the `coordinate_system` column in
+    `*_electrodes.tsv` may be omitted.
+
+1.  **Measured coordinates in a single coordinate system defined by anatomical landmarks.**
+    This approach is suitable for individual electrodes placed close together on a single
+    body part.
+    In this case the `*_coordsystem.json` file MUST contain fields `EMGCoordinateSystem`,
+    `EMGCoordinateUnits`, and `EMGCoordinateSystemDescription` as described in (1) above.
+    For example, 4 electrodes all placed on the forearm (2 on the volar surface and 2 on
+    the dorsal surface) could be located with coordinates in the following coordinate system:
+
+    -   `x`: radial styloid process (RSP) → ulnar styloid process (USP);
+    -   `y`: oleacranon process → cubital fossa;
+    -   `z`: RSP-USP → lateral humerus epicondyle
+
+    It may be possible to omit the `z` column when all electrodes are on the same surface
+    (in the above example, if all electrodes were on the volar surface and none were on
+    the dorsal surface).
+    Though it would be possible to omit both `z` and `y` if all electrodes are colinear
+    along the anatomically defined `x` axis, the `y` column is required and thus researchers
+    SHOULD enter `0` for all entries in column `y` in such cases.
+    In this case (of a single coordinate system for all electrodes) the
+    `coordinate_system` column in `*_electrodes.tsv` may be omitted as in (1) above.
+
+1.  **Measured coordinates in multiple anatomically-defined coordinate systems.**
+    This approach is suitable for individual electrodes placed on multiple body parts.
+    In this case there MUST be multiple `*_coordsystem.json` files (distinguished by the
+    `space` entity) for each coordinate system, each of which MUST contain the fields
+    `EMGCoordinateSystem`, `EMGCoordinateUnits`, and `EMGCoordinateSystemDescription` as
+    described in (1) above.
+    Additionally, the `coordinate_system` column in `*_electrodes.tsv` MUST indicate which
+    named coordinate system the coordinate values in that row reflect, by referencing the
+    label of the `space` entity for the corresponding `*_coordsystem.json` file.
+    For example, `*_space-lowerLeg_coordsystem.json` may specify a coordinate system defined
+    by lower leg landmarks for electrodes below the knee, and another called
+    `*_space-thigh_coordsystem.json` defined by upper-leg landmarks for electrodes above the knee.
+    In such a case, entries in the `coordinate_system` column of `*_electrodes.tsv` MUST
+    specify either `"lowerLeg"` or `"thigh"`.
+    As in (2) above, enter `0` for the `y` column values if all electrodes are colinear
+    along the defined `x` axis.
+
+1.  **Measured coordinates in "nested" coordinate systems.**
+    This approach is suitable for large electrode grids or similar devices.
+    In this case, measured 2D locations in the `x` and `y` columns define the geometry
+    of an electrode grid or group, relative to an arbitrary device-internal origin and
+    axes (this is the "child" coordinate system, defined for example in a file
+    `*_space-dorsalGrid_coordsystem.json`).
+    The group's placement on the body is then described by selecting an "anchor"
+    electrode and providing its coordinates within a "parent" coordinate system defined
+    in reference to subject anatomy (as in (2) above), in a separate file such as
+    `*_space-forearm_coordsystem.json`.
+    Each coordinate system file MUST contain the fields `EMGCoordinateSystem`,
+    `EMGCoordinateUnits`, and `EMGCoordinateSystemDescription` as described in (1) above.
+    Additionally, each child coordinate system file MUST contain an entry `ParentCoordinateSystem`
+    giving the value of the `space` entity for the file that defines the parent (anatomical) coordinate system,
+    and entries `AnchorElectrode` and `AnchorCoordinates` that name an electrode and provide
+    its coordinates in the parent coordinate system (respectively).
+    For example, a coordinate system called "forearm" defined by forearm anatomical landmarks
+    (as in (2) above) could be the parent coordinate system for two electrode grids placed on
+    the volar and dorsal surfaces of the forearm.
+    Each grid would have its own coordinate system file (named, for example,
+    `*_space-dorsalGrid_coordsystem.json` and `*_space-volarGrid_coordsystem.json`)
+    in which coordinates of each electrode are relative to a device-internal
+    origin, such as the lower-leftmost electrode when the device is in a specified orientation.
+    In such a scenario, entries in the `coordinate_system` column of `*_electrodes.tsv`
+    MUST specify either `"volarGrid"` or `"dorsalGrid"` for electrodes within each grid
+    (electrodes external to the grid, such as separate reference or ground electrodes, MAY
+    specify a different value in the `coordinate_system` column: typically this will be the parent
+    coordinate system or a different anatomically defined coordinate system as in (2) above).
+    Note that the parent coordinate system may be defined in different units than the child
+    coordinate system; for example, if an anchor electrode was placed 50% of the distance
+    between the ulnar styloid process and cubital fossa, the unit of the parent coordinate
+    system is `"percent"` and `AnchorCoordinates` would have a value of `50` for the `x`
+    coordinate in `*_space-volarGrid_coordsystem.json`.
+    Meanwhile, the `x` column of `*_electrodes.tsv` gives the device-internal coordinates
+    of the grid electrodes, which may be in a different unit such as `"mm"`.
+    See the [`coordsystem.json` section](#example-coordsystemjson) for further details.
+
+For details of how to specify the coordinate systems in each of these cases, see the
+[`coordsystem.json` section](#example-coordsystemjson).
+
+### Required columns
+
+The order of the required columns in the `*_electrodes.tsv` file MUST be as listed below.
+
+<!-- This block generates a columns table.
+The definitions of these fields can be found in
+  src/schema/rules/tabular_data/*.yaml
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_columns_table("emg.EMGElectrodes") }}
+
+The [`recording-<label>`](../appendices/entities.md#recording) entity MUST be used to indicate
+simultaneous acquisition of data from multiple EMG devices, in cases where the devices
+store data in separate data files.
+For example:
+
+<!-- This block generates a file tree.
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filetree_example(
+   {
+   "sub-01": {
+      "ses-01":{
+         "emg": {
+            "sub-01_ses-01_recording-RectusFemoris_electrodes.tsv": "",
+            "sub-01_ses-01_recording-VastusLateralis_electrodes.tsv": "",
+            "sub-01_ses-01_recording-VastusMedialis_electrodes.tsv": ""
+            },
+         },
+      }
+   }
+) }}
+
+Above, acquisitions are labeled with the target muscle, but other naming schemes are also
+appropriate. For example, if bipolar and grid EMG devices are used simultaneously,
+acquisitions may be labeled "bipolar" and "grid", or use the device manufacturer names.
+For cases of multiple devices recording simultaneously into _the same data file_,
+the `group` column MUST be used to distinguish which electrodes belong to which device.
+
+Except in cases of simultaneous acquisitions from different devices into different data
+files (as mentioned above), `*_electrodes.tsv` files SHOULD NOT be duplicated for each data file,
+for example, during multiple runs of a task.
+The [inheritance principle](../common-principles.md#the-inheritance-principle) MUST
+be used to find the appropriate electrode positions for a given data file.
+If electrodes are repositioned, it is RECOMMENDED to use multiple sessions to indicate this.
+
+### Example `*_electrodes.tsv`
+
+Example `*_electrodes.tsv` for a 2 by 2 grid of EMG electrodes with 2.5 mm electrode diameter
+and 10 mm inter-electrode distance.
+
+```Text
+name  x     y     coordinate_system  group  diameter
+001   0.0   0.0   VolarForearm       grid1  2.5
+002   10.0  0.0   VolarForearm       grid1  2.5
+003   0.0   10.0  VolarForearm       grid1  2.5
+004   10.0  10.0  VolarForearm       grid1  2.5
+001   0.0   0.0   DorsalForearm      grid2  2.5
+002   10.0  0.0   DorsalForearm      grid2  2.5
+003   0.0   10.0  DorsalForearm      grid2  2.5
+004   10.0  10.0  DorsalForearm      grid2  2.5
+```
+
+## Coordinate System JSON (`*_coordsystem.json`)
+
+<!--
+This block generates a filename templates.
+The inputs for this macro can be found in the directory
+  src/schema/rules/files/raw
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filename_template("raw", datatypes=["emg"], suffixes=["coordsystem"]) }}
+
+This `*_coordsystem.json` file contains the coordinate system in which electrode positions
+are expressed.
+Associated photos can also be provided.
+**The `*_coordsystem.json` is REQUIRED if the optional `*_electrodes.tsv` is specified**;
+please see the [electrodes description section](#electrodes-description-electrodestsv) for
+important guidance regarding how to specify electrode location.
+
+Fields relating to the EMG coordinate system(s):
+
+<!-- This block generates a metadata table.
+These tables are defined in
+  src/schema/rules/sidecars
+The definitions of the fields specified in these tables may be found in
+  src/schema/objects/metadata.yaml
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_json_table("json.emg.EMGCoordsystemPositions") }}
+
+The [`recording-<label>`](../appendices/entities.md#recording) entity MUST be used to indicate
+simultaneous acquisition of data from multiple EMG devices, in cases where the devices
+store data in separate data files.
+Except in cases of simultaneous acquisitions from different devices into different data
+files (as just mentioned), `*_coordsystem.json` files SHOULD NOT be duplicated for each data file,
+for example, during multiple runs of a task.
+However, multiple `*_coordsystem.json` files distinguished by the `space` entity MUST be
+used to describe separate anatomically-defined coordinate systems (for example, to situate
+devices in reference to landmarks on different limbs).
+Multiple `*_coordsystem.json` files distinguished by the `space` entity MUST also be used to describe
+_nested coordinate systems_ that give the relative positions of groups or grids of electrodes
+mounted to a single device and situate that "child" coordinate system within an anatomically-defined
+"parent" coordinate system that situates the placement multi-electrode device on the body.
+The [inheritance principle](../common-principles.md#the-inheritance-principle) MUST
+be used to find the appropriate coordinate system description for a given data file.
+
+### Example 1: `*_coordsystem.json` for digitized electrode positions
+
+Here, a coordinate system is defined based on digitized cranial landmarks, and is suitable
+for EMG electrodes on the face whose locations are digitized with the same equipment as the
+cranial landmarks:
+
+```json
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x: left helix-tragus junction (LHJ) → right helix-tragus junction (RHJ); y: inion → nasion; z: midpoint between mastoid processes → vertex",
+    "EMGCoordinateSystemUnits": "m"
+}
+```
+
+### Example 2: `*_coordsystem.json` for measured electrode positions in a single coordinate system defined by anatomical landmarks
+
+Here, a coordinate system is defined based on percentage of distances between anatomical
+landmarks of the forearm, and is suitable for localizing individual electrodes on the
+same body part:
+
+```json
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x: radial styloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
+    "EMGCoordinateSystemUnits": "percent"
+}
+```
+
+### Example 3: multiple `*_coordsystem.json` files for measured electrode positions in multiple anatomically-defined coordinate systems
+
+Here, separate anatomically-based coordinate systems are defined for electrodes above and
+below the elbow joint, and each is given a unique name ("Forearm" or "Humerus") which can
+be referenced in the `coordinate_system` column of `*_electrodes.tsv`:
+
+```json title="*_space-Forearm_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x: radial styloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
+    "EMGCoordinateSystemUnits": "percent"
+}
+```
+
+```json title="*_space-Humerus_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x: medial humerus epicondyle (MHE) → lateral humerus epicondyle (LHE), y: oleacranon process → cubital fossa, z: MHE-LHE → greater humerus tubercule",
+    "EMGCoordinateSystemUnits": "percent"
+}
+```
+
+### Example 4: multiple `*_coordsystem.json` files for nested/anchored coordinate systems
+
+Here, coordinate systems for the _relative_ locations of electrodes in grids or groups are
+given in "child" coordinate systems ("BicepGrid", "VolarForearmGrid", "DorsalForearmGrid"),
+each of which is anchored to a "parent" coordinate system that is defined anatomically:
+
+```json title="*_space-BicepGrid_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
+    "EMGCoordinateSystemUnits": "mm",
+    "ParentCoordinateSystem": "Humerus",
+    "AnchorCoordinates": [40, 70, 0],
+    "AnchorElectrode": "E1"
+}
+```
+
+```json title="*_space-VolarForearmGrid_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
+    "EMGCoordinateSystemUnits": "mm",
+    "ParentCoordinateSystem": "Forearm",
+    "AnchorCoordinates": [25, 50, 10],
+    "AnchorElectrode": "E1"
+}
+```
+
+```json title="*_space-DorsalForearmGrid_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
+    "EMGCoordinateSystemUnits": "mm",
+    "ParentCoordinateSystem": "Forearm",
+    "AnchorCoordinates": [75, 0, 90],
+    "AnchorElectrode": "E1",
+}
+```
+
+```json title="*_space-Forearm_coordsystem.json"
+{
+    "EMGCoordinateSystem": "Other",
+    "EMGCoordinateSystemDescription": "x: radial styloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
+    "EMGCoordinateSystemUnits": "percent"
+}
+```
+
+```json title="*_space-Humerus_coordsystem.json"
+{
+        "EMGCoordinateSystem": "Other",
+        "EMGCoordinateSystemDescription": "x: medial humerus epicondyle (MHE) → lateral humerus epicondyle (LHE), y: oleacranon process → cubital fossa, z: MHE-LHE → greater humerus tubercule",
+        "EMGCoordinateSystemUnits": "percent"
+}
+```
+
+## Photos of the electrode positions (`*_photo.<extension>`)
+
+<!--
+This block generates a filename templates.
+The inputs for this macro can be found in the directory
+  src/schema/rules/files/raw
+and a guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filename_template("raw", datatypes=["emg"], suffixes=["photo"]) }}
+
+Photos of the electrode locations are OPTIONAL.
+Photos SHOULD include sufficient surrounding context to distinguish anatomical location.
+For example, photographs of electrodes on the limbs should include at least one adjacent joint.
+Photos may need to be cropped and/or blurred to conceal identifying features
+or entirely omitted prior to dataset distribution, depending on obtained consent.
+
+If there are photos of the electrodes, the [`recording-<label>`](../appendices/entities.md#recording) entity
+MAY be specified, if separate photos are provided of each EMG device and the devices recorded
+into separate data files.
+The [`ses-<label>`](../appendices/entities.md#ses) entity may be used to specify when the photo was taken.
+
+### Example `*_photo.<extension>`
+
+<!-- This block generates a file tree.
+A guide for using macros can be found at
+ https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
+-->
+{{ MACROS___make_filetree_example(
+   {
+   "sub-01": {
+      "ses-01":{
+         "sub-01_ses-01_recording-DorsalForearmGrid_photo.jpg": "",
+         "...": "",
+         },
+      }
+   }
+) }}
+
+![photo of EMG electrodes](images/emg_electrodes1.png "photo of an EMG electrode grid on a subject's forearm")
diff --git a/src/modality-specific-files/images/emg_electrodes1.png b/src/modality-specific-files/images/emg_electrodes1.png
new file mode 100644
index 0000000000..5d98285492
Binary files /dev/null and b/src/modality-specific-files/images/emg_electrodes1.png differ
diff --git a/src/schema/meta/associations.yaml b/src/schema/meta/associations.yaml
index ddceeddc4f..c3cdd99f5d 100644
--- a/src/schema/meta/associations.yaml
+++ b/src/schema/meta/associations.yaml
@@ -75,7 +75,7 @@ bvec:
 
 channels:
   selectors:
-    - intersects([suffix], ['eeg', 'ieeg', 'meg', 'nirs', 'motion', 'optodes'])
+    - intersects([suffix], ['eeg', 'emg', 'ieeg', 'meg', 'nirs', 'motion', 'optodes'])
     - extension != '.json'
   target:
     suffix: channels
@@ -93,7 +93,7 @@ coordsystem:
 
 electrodes:
   selectors:
-    - intersects([suffix], ['eeg', 'ieeg', 'meg'])
+    - intersects([suffix], ['eeg', 'emg', 'ieeg', 'meg'])
     - extension != '.json'
   target:
     suffix: electrodes
@@ -101,3 +101,15 @@ electrodes:
     entities:
       - space
   inherit: true
+
+coordsystems:
+  selectors:
+    - datatype == 'emg'
+    - intersects([suffix], ['emg', 'electrodes'])
+    - extension != '.json'
+  target:
+    suffix: coordsystem
+    extension: .json
+    entities:
+      - space
+  inherit: true
diff --git a/src/schema/meta/context.yaml b/src/schema/meta/context.yaml
index bc61dd1cb2..5c4f5d8bee 100644
--- a/src/schema/meta/context.yaml
+++ b/src/schema/meta/context.yaml
@@ -269,7 +269,7 @@ properties:
             description: 'Path to associated electrodes.tsv file'
             type: string
       coordsystem:
-        description: 'Coordinate system file'
+        description: 'Coordinate system file (first found)'
         type: object
         required: [path]
         additionalProperties: false
@@ -277,6 +277,27 @@ properties:
           path:
             description: 'Path to associated coordsystem file'
             type: string
+      coordsystems:
+        description: 'Coordinate system files (all)'
+        type: object
+        required: [paths, spaces, ParentCoordinateSystems]
+        additionalProperties: false
+        properties:
+          paths:
+            description: 'Paths to associated coordsystem files'
+            type: array
+            items:
+              type: string
+          spaces:
+            description: 'Space entity labels extracted from file names'
+            type: array
+            items:
+              type: string
+          ParentCoordinateSystems:
+            description: 'ParentCoordinateSystem fields loaded from files'
+            type: array
+            items:
+              type: string
   # The following properties are populated if the current file is of an appropriate type
   columns:
     description: 'TSV columns, indexed by column header, values are arrays with column contents'
diff --git a/src/schema/objects/columns.yaml b/src/schema/objects/columns.yaml
index f5422abab2..0b46f85e74 100644
--- a/src/schema/objects/columns.yaml
+++ b/src/schema/objects/columns.yaml
@@ -92,6 +92,13 @@ component:
     - $ref: objects.enums.quat_y.value
     - $ref: objects.enums.quat_z.value
     - $ref: objects.enums.quat_w.value
+coordinate_system:
+  name: coordinate_system
+  display_name: Coordinate System
+  description: |
+    Name of the coordinate system defined in `coordsystem.json` in which the electrode's
+    `x`, `y`, and (optionally) `z` coordinates are given.
+  type: string
 detector__channels:
   name: detector
   display_name: Detector Name
@@ -179,6 +186,15 @@ group__channel:
     This is relevant because one group has one cable-bundle and noise can be shared.
     This can be a name or number.
   type: string
+group__emg:
+  name: group
+  display_name: Electrode or channel group
+  description: |
+    Which group the electrode or channel belongs to (typically this indicates electrodes
+    or bipolar channels on the same grid, strip, or other device).
+  anyOf:
+    - type: string
+    - type: number
 handedness:
   name: handedness
   display_name: Subject handedness
@@ -228,7 +244,7 @@ high_cutoff:
   description: |
     Frequencies used for the low-pass filter applied to the channel in Hz.
     If no low-pass filter applied, use `n/a`.
-    Note that hardware anti-aliasing in A/D conversion of all MEG/EEG electronics
+    Note that hardware anti-aliasing in A/D conversion of all MEG/EEG/EMG electronics
     applies a low-pass filter; specify its frequency here if applicable.
   type: number
   unit: Hz
@@ -253,6 +269,15 @@ index:
   description: |
     The label integer index.
   type: integer
+interelectrode_distance:
+  name: interelectrode_distance
+  display_name: Interelectrode Distance
+  description: |
+    Distance between adjacent electrodes (in a pair or grid) that are rigidly attached to
+    the same sensor device, or between the `signal_electrode` and its `reference`
+    when each is independently placed.
+  type: number
+  unit: mm
 low_cutoff:
   name: low_cutoff
   display_name: Low cutoff
@@ -374,6 +399,23 @@ participant_id:
     matching a participant entity found in the dataset.
   type: string
   pattern: ^sub-[0-9a-zA-Z+]+$
+placement_description:
+  name: placement_description
+  display_name: Placement Scheme Description
+  description: |
+    Additional details of the approach to EMG sensor placement.
+    See description of the `EMGPlacementSchemeDescription` field in `*_emg.json`.
+  type: string
+placement_scheme:
+  name: placement_scheme
+  display_name: Placement Scheme
+  description: |
+    A description of the electrode placement procedure used.
+    See description of the `EMGPlacementScheme` field in `*_emg.json`.
+  type: string
+  enum:
+    - measured
+    - other
 placement__motion:
   name: placement
   display_name: Placement
@@ -397,6 +439,16 @@ reference__eeg:
     This column is not needed when it is common to all channels.
     In that case the reference electrode(s) can be specified in `*_eeg.json` as `EEGReference`).
   type: string
+# reference column for channels.tsv files for EMG data
+reference__emg:
+  name: reference
+  display_name: Reference electrode
+  description: |
+    The reference for the given channel.
+    When the reference is an electrode in `*_electrodes.tsv`, use the name of that electrode.
+    For channels originating from bipolar devices, use `"bipolar"`.
+    For non-EMG channels (for example, trigger channels, microphones) use `"n/a"`.
+  type: string
 # reference column for channels.tsv files for iEEG data
 reference__ieeg:
   name: reference
@@ -513,6 +565,13 @@ short_channel:
     The total number of channels listed as short channels
     SHOULD be stored in `ShortChannelCount` in `*_nirs.json`.
   type: boolean
+signal_electrode:
+  name: signal_electrode
+  display_name: Signal electrode
+  description: |
+    The name of the electrode from which the `reference`'s signal is subtracted to yield the channel's data.
+    For channels originating from bipolar devices, the `signal_electrode` MAY be the same as the channel `name`.
+  type: string
 size:
   name: size
   display_name: Electrode size
@@ -608,6 +667,14 @@ strain_rrid:
     of the strain of the species, for example: `RRID:IMSR_JAX:000664`.
   type: string
   format: rrid
+target_muscle:
+  name: target_muscle
+  display_name: Target muscle
+  description: |
+    Name of the muscle(s) from which the EMG signal in this channel is believed to originate.
+    When exact muscle is unknown (such as when using electrode grids that cover multiple muscles),
+    groups of muscles may be named instead (for example "flexors of the left forearm").
+  type: string
 time:
   name: time
   display_name: Time
diff --git a/src/schema/objects/common_principles.yaml b/src/schema/objects/common_principles.yaml
index 1ebfe3dfe7..701050d79f 100644
--- a/src/schema/objects/common_principles.yaml
+++ b/src/schema/objects/common_principles.yaml
@@ -6,8 +6,9 @@
 data_acquisition:
   display_name: Data acquisition
   description: |
-    A continuous uninterrupted block of time during which a brain scanning instrument was acquiring data according to
-    particular scanning sequence/protocol.
+    A continuous uninterrupted block of time during which a brain scanning instrument
+    or an electromyography recording device was acquiring data
+    according to a particular scanning sequence/protocol.
 data_type:
   display_name: Data type
   description: |
@@ -45,11 +46,14 @@ data_type:
 
         15. `phenotype` (measurement and survey data)
 
+        16. `emg` (electromyography)
+
     For files that are subject- and session- specific, the data type directory
     is nested inside those directories.
     `phenotype` data files are aggregated across subjects and sessions,
     and so the `phenotype/` directory is placed in the dataset root.
 
+
 dataset:
   display_name: Dataset
   description: |
diff --git a/src/schema/objects/datatypes.yaml b/src/schema/objects/datatypes.yaml
index 333cc4d922..b3fdc455e3 100644
--- a/src/schema/objects/datatypes.yaml
+++ b/src/schema/objects/datatypes.yaml
@@ -20,6 +20,10 @@ eeg:
   value: eeg
   display_name: Electroencephalography
   description: Electroencephalography
+emg:
+  value: emg
+  display_name: Electromyography
+  description: Measurements of muscular activity.
 fmap:
   value: fmap
   display_name: Field maps
diff --git a/src/schema/objects/enums.yaml b/src/schema/objects/enums.yaml
index 19e0e30307..b70641a927 100644
--- a/src/schema/objects/enums.yaml
+++ b/src/schema/objects/enums.yaml
@@ -7,6 +7,10 @@ _EEGCoordSys:
     - $ref: objects.enums.EEGLAB.value
     - $ref: objects.enums.EEGLAB-HJ.value
     - $ref: objects.enums.Other.value
+_EMGCoordSys:
+  type: string
+  enum:
+    - $ref: objects.enums.Other.value
 _GeneticLevelEnum:
   type: string
   enum:
@@ -756,11 +760,14 @@ LATENCY:
   value: LATENCY
   display_name: LATENCY
   tags:
+    - emg
     - motion
   description: |
     Latency of samples in seconds from recording onset.
     MUST be in form of `ss[.000000]`,
     where `[.000000]` is an optional subsecond resolution between 1 and 6 decimal points.
+    Note that `LATENCY` channels typically contain timestamps from an _external_ clock
+    source, often with the intent of synchronizing data across multiple devices.
 MAGN:
   value: MAGN
   display_name: MAGN
@@ -775,6 +782,7 @@ MISC:
   display_name: MISC
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -795,6 +803,7 @@ POS:
   value: POS
   display_name: POS
   tags:
+    - emg
     - motion
   description: |
     Position in space, one channel for each spatial axis.
@@ -832,6 +841,7 @@ EOG:
   display_name: EOG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -842,6 +852,7 @@ ECG:
   display_name: ECG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -852,6 +863,7 @@ EMG:
   display_name: EMG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -879,6 +891,7 @@ HEOG:
   display_name: HEOG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -906,6 +919,7 @@ REF:
   display_name: REF
   tags:
     - eeg
+    - emg
     - ieeg
   description: |
     Reference channel.
@@ -921,11 +935,14 @@ SYSCLOCK:
   display_name: SYSCLOCK
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
   description: |
-    System time showing elapsed time since trial started.
+    Elapsed time since trial/recording start, as provided by the recording device.
+    For device-external timestamp signals, use `LATENCY`.
+    For TTL-based synchronization signals, use `TRIG`.
 TEMP:
   value: TEMP
   display_name: TEMP
@@ -938,6 +955,7 @@ TRIG:
   display_name: TRIG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
@@ -948,6 +966,7 @@ VEOG:
   display_name: VEOG
   tags:
     - eeg
+    - emg
     - meg
     - ieeg
     - fnirs
diff --git a/src/schema/objects/metadata.yaml b/src/schema/objects/metadata.yaml
index 5540049f96..6804524b98 100644
--- a/src/schema/objects/metadata.yaml
+++ b/src/schema/objects/metadata.yaml
@@ -9,6 +9,25 @@ ACCELChannelCount:
     Number of acceleration channels.
   type: integer
   minimum: 0
+AnchorCoordinates:
+  name: AnchorCoordinates
+  display_name: Anchor Coordinates
+  description: |
+    Coordinates of the `AnchorElectrode` in the parent (anatomical) coordinate system.
+    This should be an array of numbers of length 3, in the units given in
+    `EMGCoordinateSystemUnits` within the JSON object named in `ParentCoordinateSystem`.
+  type: array
+  minItems: 1
+  maxItems: 3
+  items:
+    type: number
+AnchorElectrode:
+  name: AnchorElectrode
+  display_name: Anchor Electrode
+  description: |
+    Name of the electrode in the child (device) coordinate system whose coordinates in
+    the parent (anatomical) coordinate system are given in `AnchorCoordinates`.
+  type: string
 Acknowledgements:
   name: Acknowledgements
   display_name: Acknowledgements
@@ -1010,6 +1029,25 @@ EEGReference:
     this field should have a general description and the channel specific
     reference should be defined in the `channels.tsv` file.
   type: string
+ElectrodeMaterial:
+  name: ElectrodeMaterial
+  display_name: Electrode Material
+  description: |
+    Material of the electrode (for example, `Tin`, `Ag/AgCl`, `Gold`).
+    If multiple sensor devices with heterogeneous electrode materials are recorded into
+    the same data file,
+    electrode material SHOULD be recorded in the `material` column of `*_electrodes.tsv` instead.
+    If instead those devices were recorded into separate data files (distinguished for example
+    by the `recording` entity),
+    separate `*_emg.json` files (similarly distinguished) MAY be included,
+    each with their own `ElectrodeMaterial` values.
+  type: string
+ElectrodeType:
+  name: ElectrodeType
+  display_name: Electrode type
+  description: |
+    Type of the electrode (for example, cup, ring, clip-on, wire, needle).
+  type: string
 EMGChannelCount:
   name: EMGChannelCount
   display_name: EMG Channel Count
@@ -1017,6 +1055,92 @@ EMGChannelCount:
     Number of EMG channels.
   type: integer
   minimum: 0
+EMGCoordinateSystem:
+  name: EMGCoordinateSystem
+  display_name: EMG Coordinate System
+  description: |
+    Defines the coordinate system for the EMG sensors.
+
+    See the
+    [Coordinate Systems Appendix](SPEC_ROOT/appendices/coordinate-systems.md)
+    for a list of restricted keywords for coordinate systems.
+    If `"Other"`, provide definition of the coordinate system in
+    `EMGCoordinateSystemDescription`.
+  anyOf:
+    - $ref: objects.enums._EMGCoordSys
+EMGCoordinateSystemDescription:
+  name: EMGCoordinateSystemDescription
+  display_name: EMG Coordinate System Description
+  description: |
+    Free-form text description of the coordinate system, typically defining the origin
+    and positive x,y,z axis directions, relative to anatomical landmarks.
+    May also include a link to a documentation page or paper describing the
+    system in greater detail.
+  type: string
+EMGCoordinateUnits:
+  name: EMGCoordinateUnits
+  display_name: EMG Coordinate Units
+  description: |
+    Units of the coordinates of `EMGCoordinateSystem`.
+  type: string
+  enum:
+    - m
+    - mm
+    - cm
+    - percent
+    - n/a
+EMGGround:
+  name: EMGGround
+  display_name: EMG Ground
+  description: |
+    Description of the location of the ground electrode
+    (for example, `"right radial styloid process"`).
+  type: string
+EMGPlacementScheme:
+  name: EMGPlacementScheme
+  display_name: EMG Placement Scheme
+  description: |
+    The way in which electrode placement locations were determined.
+    If electrode locations are provided as coordinates in `*_electrodes.tsv` in reference
+    to a coordinate system defined in `*_coordsystem.json`, then specify `"Measured"`.
+    If approach to placement varied across sensor devices, specify `"ChannelSpecific"`
+    and include placement details in the `placement_scheme` column of `*_channels.tsv`.
+    If a standardized electrode placement procedure (for example, SENIAM 8) was followed,
+    or if an ad-hoc procedure was followed, specify `"Other"` and provide details in
+    `EMGPlacementSchemeDescription`.
+  type: string
+  enum:
+    - ChannelSpecific
+    - Measured
+    - Other
+EMGPlacementSchemeDescription:
+  name: EMGPlacementSchemeDescription
+  display_name: EMG Placement Scheme Description
+  description: |
+    Additional details of the approach to EMG sensor placement.
+    Descriptions SHOULD NOT simply give the name of the targeted muscle (use the
+    `target_muscle` column in `*_channels.tsv` for that), but rather SHOULD reflect the
+    process used by the researcher(s) when placing electrodes.
+    For example, EMG electrode sites may be chosen by *measured distance* from anatomical
+    landmarks, by *visual reference* to (parts of) target muscles, by *palpation* of the
+    skin to locate target muscles, or by *functional localization* (temporary electrode
+    placement at several sites during prescribed behavior, until a site yielding strong
+    EMG signal is found).
+  type: string
+EMGReference:
+  name: EMGReference
+  display_name: EMG Reference
+  description: |
+    Description of the approach to signal referencing.
+    If the same signal source is used as reference for all channels (often called a
+    "monopolar" recording), specify the signal source (typically an electrode name).
+    If different channels have different reference electrodes, this field SHOULD contain
+    the string `"ChannelSpecific"` and each channel's reference SHOULD be given in the
+    `reference` column of `*_channels.tsv`.
+    For bipolar recording devices (where a single sensor unit contains two rigidly
+    separated contacts, and the paired contacts are not listed independently in
+    `*_electrodes.tsv`), this field SHOULD be `"Bipolar"`.
+  type: string
 EOGChannelCount:
   name: EOGChannelCount
   display_name: EOG Channel Count
@@ -1374,6 +1498,13 @@ Funding:
   type: array
   items:
     type: string
+Gain:
+  name: Gain
+  display_name: Gain
+  description: |
+    Signal gain from an in-line amplifier, applied between the EMG sensor/device and the data acquisition computer.
+    See also Preamplification.
+  type: number
 GeneratedBy:
   name: GeneratedBy
   display_name: Generated By
@@ -1804,6 +1935,21 @@ IntendedFor__ds_relative:
             format: bids_uri
           - type: string
             format: dataset_relative
+InterelectrodeDistance:
+  name: InterelectrodeDistance
+  display_name: Inter-electrode Distance
+  description: |
+    Distance between pairs or grids of electrodes rigidly attached to the same sensor device.
+    If multiple sensor devices with heterogeneous inter-electrode distances are recorded into
+    the same data file,
+    inter-electrode distance SHOULD be recorded in the `interelectrode_distance` column of
+    `*_electrodes.tsv` instead.
+    If instead those devices were recorded into separate data files (distinguished for example
+    by the `recording` entity),
+    separate `*_emg.json` files (similarly distinguished) MAY be included,
+    each with their own `InterelectrodeDistance` values.
+  type: number
+  unit: mm
 InversionTime:
   name: InversionTime
   display_name: Inversion Time
@@ -2625,6 +2771,13 @@ ParallelReductionFactorOutOfPlane:
     Corresponds to [DICOM Tag 0018, 9155](https://dicomlookup.com/dicomtags/(0018,9155))
     `Parallel Reduction Factor out-of-plane`.
   type: number
+ParentCoordinateSystem:
+  name: ParentCoordinateSystem
+  display_name: Parent Coordinate System
+  description: |
+    The name of a JSON mapping key that defines the parent (anatomical) coordinate system
+    in which this child (device) coordinate system is anchored.
+  type: string
 PartialFourier:
   name: PartialFourier
   display_name: Partial Fourier
@@ -2811,6 +2964,13 @@ PowerLineFrequency:
     - type: string
       enum:
         - n/a
+Preamplification:
+  name: Preamplification
+  display_name: Preamplification
+  description: |
+    Amplification built into an EMG bipolar sensor, electrode grid, or other device.
+    See also Gain.
+  type: number
 PromptRate:
   name: PromptRate
   display_name: Prompt Rate
@@ -3432,6 +3592,13 @@ SinglesRate:
   type: array
   items:
     type: number
+SkinPreparation:
+  name: SkinPreparation
+  display_name: Skin Preparation
+  description: |
+    How skin was prepared prior to sensor device placement, for example, `"alcohol wipe"`
+    or `"abrasive gel"`.
+  type: string
 SkullStripped:
   name: SkullStripped
   display_name: Skull Stripped
diff --git a/src/schema/objects/modalities.yaml b/src/schema/objects/modalities.yaml
index b80c73d0e1..f363180534 100644
--- a/src/schema/objects/modalities.yaml
+++ b/src/schema/objects/modalities.yaml
@@ -8,6 +8,10 @@ eeg:
   display_name: Electroencephalography
   description: |
     Data acquired with EEG.
+emg:
+  display_name: Electromyography
+  description: |
+    Data acquired with EMG.
 ieeg:
   display_name: Intracranial Electroencephalography
   description: |
diff --git a/src/schema/objects/suffixes.yaml b/src/schema/objects/suffixes.yaml
index 1e2825ced2..17a501b185 100644
--- a/src/schema/objects/suffixes.yaml
+++ b/src/schema/objects/suffixes.yaml
@@ -611,7 +611,12 @@ electrodes:
   value: electrodes
   display_name: Electrodes
   description: |
-    File that gives the location of (i)EEG electrodes.
+    File that gives the location of (i)EEG or EMG electrodes.
+emg:
+  value: emg
+  display_name: Electromyography
+  description: |
+    Electromyography recording data.
 epi:
   value: epi
   display_name: EPI
diff --git a/src/schema/rules/checks/channels.yaml b/src/schema/rules/checks/channels.yaml
index 7e647dc2be..a9eddc55cd 100644
--- a/src/schema/rules/checks/channels.yaml
+++ b/src/schema/rules/checks/channels.yaml
@@ -42,5 +42,6 @@ RequiredCoordsystem:
   selectors:
     - suffix == "electrodes"
     - extension == ".tsv"
+    - datatype != "emg" # coordsys file may have space entity that electrodes.tsv lacks
   checks:
-    - associations.coordsystem != null
+    - associations.coordsystem != null || associations.coordsystems != null
diff --git a/src/schema/rules/checks/emg.yaml b/src/schema/rules/checks/emg.yaml
new file mode 100644
index 0000000000..b8f35864ee
--- /dev/null
+++ b/src/schema/rules/checks/emg.yaml
@@ -0,0 +1,42 @@
+---
+EMGCoordSysMatch:
+  issue:
+    code: EMG_COORD_SYS_MISMATCH
+    message: |
+      Some values in the coordinate_system column of *_electrodes.tsv are not present as
+      space entities in *_coordsystem.json files.
+    level: error
+  selectors:
+    - datatype == "emg"
+    - suffix == "electrodes"
+    - columns.coordinate_system
+  checks:
+    # ↓ any LABEL that is mentioned in `coordinate_system` column of `*_electrodes.tsv`
+    # ↓ must have an associated file `*_space-LABEL_coordsystem.json`
+    - |
+      length(
+        intersects(
+          unique(columns.coordinate_system),
+          associations.coordsystems.spaces
+        )
+      ) == length(unique(columns.coordinate_system))
+
+EMGCoordSysParents:
+  issue:
+    code: EMG_COORD_SYS_PARENTS
+    message: Some parent coordinate systems were not found.
+    level: error
+  selectors:
+    - datatype == "emg"
+    - suffix == "electrodes"
+    - length(associations.coordsystems.ParentCoordinateSystems)
+  checks:
+    # ↓ any LABEL that is mentioned as a ParentCoordinateSystem must have an associated
+    # ↓ file `*_space-LABEL_coordsystem.json`
+    - |
+      length(
+        intersects(
+          unique(associations.coordsystems.ParentCoordinateSystems),
+          associations.coordsystems.spaces
+        )
+      ) == length(unique(associations.coordsystems.ParentCoordinateSystems))
diff --git a/src/schema/rules/errors.yaml b/src/schema/rules/errors.yaml
index 5c8fd069a1..e5b42a316b 100644
--- a/src/schema/rules/errors.yaml
+++ b/src/schema/rules/errors.yaml
@@ -142,6 +142,8 @@ SidecarWithoutDatafile:
   level: error
   selectors:
     - extension == ".json"
+    - suffix != "coordsystem" || modality != "emg"
+    # ↑ EMG allows multiple coordsys files per data file (distinguished via `space` entity)
 
 # BIDS Validator Original Issue Code #97
 MissingSession:
diff --git a/src/schema/rules/files/raw/channels.yaml b/src/schema/rules/files/raw/channels.yaml
index 6a4358c689..62d49e5d9a 100644
--- a/src/schema/rules/files/raw/channels.yaml
+++ b/src/schema/rules/files/raw/channels.yaml
@@ -16,6 +16,15 @@ channels:
     acquisition: optional
     run: optional
 
+# emg may have a `recording` entity
+channels__emg:
+  $ref: rules.files.raw.channels.channels
+  datatypes:
+    - emg
+  entities:
+    $ref: rules.files.raw.channels.channels.entities
+    recording: optional
+
 # MEG has an additional entity available
 channels__meg:
   $ref: rules.files.raw.channels.channels
@@ -58,30 +67,56 @@ coordsystem__eeg:
     $ref: rules.files.raw.channels.coordsystem.entities
     space: optional
 
+# emg may have a `recording` entity
+coordsystem__emg:
+  $ref: rules.files.raw.channels.coordsystem__eeg
+  datatypes:
+    - emg
+  entities:
+    $ref: rules.files.raw.channels.coordsystem__eeg.entities
+    recording: optional
+    space: optional
+
 electrodes:
   suffixes:
     - electrodes
   extensions:
     - .json
     - .tsv
-  datatypes:
-    - eeg
-    - ieeg
+  datatypes: []
   entities:
     subject: required
     session: optional
     task: optional
     acquisition: optional
     run: optional
+
+# EMG can have `recording` entity (for multiple simultaneous devices)
+electrodes__emg:
+  $ref: rules.files.raw.channels.electrodes
+  datatypes:
+    - emg
+  entities:
+    $ref: rules.files.raw.channels.electrodes.entities
+    recording: optional
+
+# (i)EEG can have `space` entity
+electrodes__eeg:
+  $ref: rules.files.raw.channels.electrodes
+  datatypes:
+    - eeg
+    - ieeg
+  entities:
+    $ref: rules.files.raw.channels.electrodes.entities
     space: optional
 
-# MEG has an additional entity available
+# MEG can have `space` (like EEG) and also `processing`
 electrodes__meg:
-  $ref: rules.files.raw.channels.electrodes
+  $ref: rules.files.raw.channels.electrodes__eeg
   datatypes:
     - meg
   entities:
-    $ref: rules.files.raw.channels.electrodes.entities
+    $ref: rules.files.raw.channels.electrodes__eeg.entities
     processing: optional
 
 optodes:
diff --git a/src/schema/rules/files/raw/emg.yaml b/src/schema/rules/files/raw/emg.yaml
new file mode 100644
index 0000000000..7d4b29ad09
--- /dev/null
+++ b/src/schema/rules/files/raw/emg.yaml
@@ -0,0 +1,17 @@
+---
+emg:
+  suffixes:
+    - emg
+  extensions:
+    - .json
+    - .edf
+    - .bdf
+  datatypes:
+    - emg
+  entities:
+    subject: required
+    session: optional
+    task: required
+    acquisition: optional
+    run: optional
+    recording: optional
diff --git a/src/schema/rules/files/raw/events.yaml b/src/schema/rules/files/raw/events.yaml
index 7800b946df..1280729a59 100644
--- a/src/schema/rules/files/raw/events.yaml
+++ b/src/schema/rules/files/raw/events.yaml
@@ -21,6 +21,14 @@ events:
 # Specializations
 # In these rules, we use $ref to retrieve most of an object, and then override
 
+events__emg:
+  $ref: rules.files.raw.events.events
+  datatypes:
+    - emg
+  entities:
+    $ref: rules.files.raw.events.events.entities
+    recording: optional
+
 events__mri:
   $ref: rules.files.raw.events.events
   datatypes:
diff --git a/src/schema/rules/files/raw/photo.yaml b/src/schema/rules/files/raw/photo.yaml
index f5969e2d0c..b47d8f1c96 100644
--- a/src/schema/rules/files/raw/photo.yaml
+++ b/src/schema/rules/files/raw/photo.yaml
@@ -16,6 +16,14 @@ photo:
     session: optional
     acquisition: optional
 
+photo__emg:
+  $ref: rules.files.raw.photo.photo
+  datatypes:
+    - emg
+  entities:
+    $ref: rules.files.raw.photo.photo.entities
+    recording: optional
+
 photo__micr:
   $ref: rules.files.raw.photo.photo
   extensions:
diff --git a/src/schema/rules/json/emg.yaml b/src/schema/rules/json/emg.yaml
new file mode 100644
index 0000000000..08879cf830
--- /dev/null
+++ b/src/schema/rules/json/emg.yaml
@@ -0,0 +1,67 @@
+#
+# Groups of related metadata fields
+#
+# Assumptions: never need disjunction of selectors
+# Assumptions: top-to-bottom overrides is sufficient logic
+
+---
+# ensure presence of fields relating to the EMG electrode positions
+EMGCoordsystemPositions:
+  selectors:
+    - datatype == "emg"
+    - suffix == "coordsystem"
+  fields:
+    EMGCoordinateSystem: required
+    EMGCoordinateUnits: required
+    EMGCoordinateSystemDescription:
+      level: recommended
+      level_addendum: required if `EMGCoordinateSystem` is `"Other"`
+    ParentCoordinateSystem: optional
+    AnchorCoordinates:
+      level: optional
+      level_addendum: required if `ParentCoordinateSystem` is present
+    AnchorElectrode:
+      level: optional
+      level_addendum: required if `ParentCoordinateSystem` is present
+
+# ensure description is present when coordsys is "other"
+EMGCoordsystemOther:
+  selectors:
+    - datatype == "emg"
+    - suffix == "coordsystem"
+    - '"EMGCoordinateSystem" in json'
+    - json.EMGCoordinateSystem == "Other"
+  fields:
+    EMGCoordinateSystemDescription: required
+
+# ensure linkage between child (device) and parent (anatomical) coordinate systems
+EMGChildCoordSystem:
+  selectors:
+    - datatype == "emg"
+    - suffix == "coordsystem"
+    - '"ParentCoordinateSystem" in json'
+  fields:
+    AnchorCoordinates: required
+    AnchorElectrode: required
+
+# ensure presence of fields relating to EMG placement
+EMGPlacementSchemeInfo:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    EMGPlacementScheme: required
+    EMGPlacementSchemeDescription:
+      level: optional
+      level_addendum: required if `EMGPlacementScheme` is `"Other"`
+
+# ensure description is present when EMGPlacementScheme is "other"
+EMGPlacementSchemeDescription:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+    - '"EMGPlacementScheme" in json'
+    - json.EMGPlacementScheme == "Other"
+  fields:
+    EMGPlacementSchemeDescription:
+      level: required
diff --git a/src/schema/rules/modalities.yaml b/src/schema/rules/modalities.yaml
index ccba1c3ef1..6aa492a8a0 100644
--- a/src/schema/rules/modalities.yaml
+++ b/src/schema/rules/modalities.yaml
@@ -10,6 +10,9 @@ mri:
 eeg:
   datatypes:
     - eeg
+emg:
+  datatypes:
+    - emg
 ieeg:
   datatypes:
     - ieeg
diff --git a/src/schema/rules/sidecars/emg.yaml b/src/schema/rules/sidecars/emg.yaml
new file mode 100644
index 0000000000..805f745b3e
--- /dev/null
+++ b/src/schema/rules/sidecars/emg.yaml
@@ -0,0 +1,89 @@
+#
+# Groups of related metadata fields
+#
+# Assumptions: never need disjunction of selectors
+# Assumptions: top-to-bottom overrides is sufficient logic
+
+---
+EMGHardware:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    Manufacturer: recommended
+    ManufacturersModelName: recommended
+    SoftwareVersions: recommended
+    DeviceSerialNumber: recommended
+    ElectrodeManufacturer: recommended
+    ElectrodeManufacturersModelName: recommended
+
+EMGTaskInformation:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    TaskName:
+      level: required
+      description_addendum: |
+        A recommended convention is to name resting state task using labels
+        beginning with `rest`.
+    TaskDescription: recommended
+    Instructions:
+      level: recommended
+      description_addendum: |
+        This is especially important in context of resting state recordings, to distinguish
+        resting positions with different postures (for example, `"seated"`, `"reclined"`).
+
+EMGInstitutionInformation:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    InstitutionName: recommended
+    InstitutionAddress: recommended
+    InstitutionalDepartmentName: recommended
+
+# Specific EMG fields MUST be present
+EMGRequired:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    EMGPlacementScheme: required
+    EMGReference: required
+    SamplingFrequency:
+      level: required
+      description_addendum: |
+        The sampling frequency of data channels that deviate from the main sampling
+        frequency SHOULD be specified in the `channels.tsv` file.
+    PowerLineFrequency: required
+    SoftwareFilters: required
+
+# Specific EMG fields SHOULD be present
+EMGRecommended:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    ElectrodeMaterial: recommended
+    ElectrodeType: recommended
+    EMGChannelCount: recommended
+    EMGGround: recommended
+    EMGPlacementSchemeDescription: recommended
+    EpochLength: recommended
+    HardwareFilters: recommended
+    Preamplification: recommended
+    Gain: recommended
+    InterelectrodeDistance: recommended
+    RecordingDuration: recommended
+    RecordingType: recommended
+    SubjectArtefactDescription: recommended
+    TriggerChannelCount: recommended
+
+# Specific EMG fields MAY be present
+EMGOptional:
+  selectors:
+    - datatype == "emg"
+    - suffix == "emg"
+  fields:
+    SkinPreparation: optional
diff --git a/src/schema/rules/tabular_data/emg.yaml b/src/schema/rules/tabular_data/emg.yaml
new file mode 100644
index 0000000000..ae6303d646
--- /dev/null
+++ b/src/schema/rules/tabular_data/emg.yaml
@@ -0,0 +1,54 @@
+---
+EMGChannels:
+  selectors:
+    - datatype == "emg"
+    - suffix == "channels"
+    - extension == ".tsv"
+  initial_columns:
+    - name__channels
+    - type__channels
+    - units
+  columns:
+    name__channels: required
+    type__channels: required
+    units: required
+    description: optional
+    sampling_frequency: optional
+    signal_electrode: recommended
+    reference__emg: recommended
+    group__emg: recommended
+    target_muscle: recommended
+    placement_scheme: recommended
+    placement_description: recommended
+    interelectrode_distance: recommended
+    low_cutoff: optional
+    high_cutoff: optional
+    notch: optional
+    status: optional
+    status_description: optional
+  index_columns: [name__channels]
+  additional_columns: allowed_if_defined
+
+EMGElectrodes:
+  selectors:
+    - datatype == "emg"
+    - suffix == "electrodes"
+    - extension == ".tsv"
+  initial_columns:
+    - name__electrodes
+    - x
+    - y
+    - z
+    - coordinate_system
+  columns:
+    name__electrodes: required
+    x: required
+    y: required
+    z: optional
+    coordinate_system: recommended
+    type__electrodes: recommended
+    material: recommended
+    impedance: recommended
+    group__emg: recommended
+  index_columns: [name__electrodes, group__emg]
+  additional_columns: allowed_if_defined