Skip to main content

Qube Monthly Report Primary Governance Document

1. Primary Document

1.1. Introduction

This document articulates the digital credential for the Qube Data Report submitted on a monthly basis.

The development of this documentation follows the governance framework created by the Trust over IP Foundation (ToIP) Governance Metamodel Specification created by the Governance Stack Working Group (GSWG).

These materials are made available under and are subject to the Creative Commons Attribution 4.0 International license.

THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user.

IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Acknowledgements

This governance framework includes structural elements from the Trust over IP Metamodel that were developed by Governance Stack Working Group of the Trust over IP Foundation, the eSSIF Lab Glossary and Mental Models, were contributed to the Trust Over IP Foundation under the CC BY-SA 4.0 license. There have also been contributions from the Concepts & Terminology Working Group at ToIP, the Human Experience Working Group at ToIP and the Ecosystem Foundry Working Group at ToIP, the work of the Governance Framework Working Group at Sovrin Foundation is also acknowledged in providing support.

1.2. Terminology and Notation

Glossary - General Trust Over IP Terms

Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119.

  • Mandates are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
  • Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
  • Options are Requirements that use a MAY or OPTIONAL keyword.

Machine-Testable Requirements are those with which compliance can be verified using an automated test suite and appropriate scripting or testing software.

Rules are Machine-Testable Requirements that are written in a Machine-Readable language and can be processed by a Rules Engine. They are expressed in a structured rules language as specified by the Governance Framework.

Human-Auditable Requirements are those with which compliance can only be verified by an audit of people, processes, and procedures.

Policies are Human-Auditable Requirements written using standard conformance terminology. The Policies used in the Governance Framework will use the standard terminology detailed in RFC 2119 keywords. Note that all RFC 2119 keywords have weight from an auditing perspective. An implementer MUST explain why a SHOULD or RECOMMENDED requirement was not implemented and SHOULD explain why a MAY requirement was implemented.

Specifications are documents containing any combination of Machine-Testable Requirements and Human-Auditable Requirements needed to produce technical interoperability.

1.3. Localization

The standard language for this governing framework (GF) is English.  

1.4. Governing Authority

Qube Technologies (Qube) is the governing authority and responsible for developing, maintaining and implementing the Governance Framework.

1.5. Administering Authority

Energy and Mines Digital Trust (EMDT) is the Administering Authority on behalf of Qube during the pilot phase of development.

The contact information for EMDT is:

  • Name: Kyle Robinson
  • Title: Senior Strategic Advisor, Digital Trust Ecosystems
  • Organization: Briartech Consulting Inc.
  • Email: kyle.robinson@briartech.ca

1.6. Purpose

The purpose of this Governance Framework (GF) is to define the parameters of a Qube Report Credential. The structure for the credential contains all information needed to fulfill a Qube Report. This credential is issued directly by Qube, which transfers aggregated methane emission volume data based on the time period selected at the site level to the site owner.

1.7. Scope

The GF only covers the Qube Report Credential.

1.8. Objectives

This GF describes the Qube Report Credential consisting of data elements captured and included within a Qube Report and as defined by Qube API data elements and standards. A list of these can be found on the Qube Platfrom API (V2.0) https://api.qubeiot.com/index.html. The API allows the retrieval of sites, emissions, measurements and wind data. Qube Technologies seeks to apply meaningful greenhouse gas reduction delivered in three stages (detection, measurement and reduction). This trust framework outlines Qube's issuance of a credential based off of Schemas built from Qube Platform API data referenced above.

1.9. Principles

TBD

1.10. General Requirements

A Qube Report Credential MUST be issued by Qube. The API referenced in the Schema Definition section of this document allows the retrieval of sites, emissions, measurements and wind data. The API is a REST based API that returns data in JSON format.

1.11. Revisions

Version 1.0.

1.12. Extensions

There are no extensions to this Governance Framework.

1.13. Schedule of Controlled Documents

TBD

2. Controlled Documents

2.1. Glossary

TBD

2.2. Risk Assessment

TBD

2.3. Trust Assurance and Certification

TBD

2.4. Governance Requirements

TBD

2.5. Business Requirements

TBD

2.6. Technical Requirements

2.6.1. Schema Definition

Schema Name: qube.report

Schema Version: 1.0

This schema definition follows the AnonCreds specification (https://anoncreds-wg.github.io/anoncreds-spec/)

AttributeFormatRulesNotes
site_aliasesStringnot NULLSite alias can be defined as the parent company's name or as determined by company.
site_idStringnot NULLSite ID is a numerical identifier generated by Qube.
site_nameStringnot NULLSite name as defined by the company.
from_timeStringnot NULLMethane emission data that have occurred on or after this timestamp (example 2023-02-08T16:10:51Z).
to_timeStringnot NULLMethane emission data that have occurred on or before this timestamp (example 2023-02-08T16:25:51Z).
equipmentStringnot NULLThe identified piece of equipment involved in an emission. If null then a piece of equipment could not be identified as being associated with the emission.
equipment_groupsStringnot NULLThe array of objects that pertain to group characteristics (SiteEquipmentGroupModel), exacmple tanks.
group_by_equipment_categoryStringnot NULLWhen set to true the aggregated volumes are additionally grouped by equipment category.
sampling_methodStringnot NULLOptionally specify the sampling method to use when sampling site rates.
sample_periodStringnot NULLOptionally sample the site rates to a specified sampling period.
group_by_periodStringnot NULLThe period by which to group the aggregated volumes.
total_volumeStringnot NULLThe total volume of methane emissions emitted over the course of the prescribed timeframe.
measurement_typesStringnot NULLThe type of measurements that should be returned.
device_filterStringnot NULLA definition of what devices to filter by. You can specify either: 1) a site alias
production_dataStringnot NULLunder review, number may need to be provided by Xpansive
thresholds_minStringnot NULLunder review, number may need to be provided by Xpansive
thresholds_maxStringnot NULLunder review, number may need to be provided by Xpansive

2.7. Information Trust Requirements

See Qube's Privacy Policy

2.8. Inclusion, Equitability, and Accessibility Requirements

TBD

TBD

End of Document