# Proof of Supervision with Blockchain ## Licensing Boards and Working Groups {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/collective" %} [collective](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/collective) {% endcontent-ref %} The licensing boards will be constructed from the `collective` pallet. We will also introduce a `working group` technical committee. Working groups define the standard of care for each category of work on the network. {% hint style="info" %} ## Licensing Board ## Objective A board of directors with the same voting authorities issued by the local legislation, but now all voting would be on the blockchain, including approval and review of license applications. {% endhint %} {% hint style="warning" %} ## Working Group **Scope\** #### Discipline\ ## Objective A standard of care working group organized around the objective to establish a standard of care for a discipline type. In this case, Electrical. It is the responsibility of the working group to establish a minimum standard of care for electrical design in a manner that * helps assure public safety * without imposing erroneous administrative work on the community that would discourage engagement in compliance * members of the working group should propose a `standard`\_`of_care` and internally vote on the final version. * this final version would then go to the network as the proposed standard of care for the network * submissions will implement the `staking` mechanism (ie the group would collectively bond the proposal, receiving the bond back if adopted by the community * only one formal `standard_of_care` may exist per category. * `standard_of_care` era is set to six months and is voted for adoption by network every six months. Any working group may submit an updated standard of care during that time if they have a better version. The network will vote on the standard of care. {% endhint %} ## Professional Engineering License {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/identity" %} [identity](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/identity) {% endcontent-ref %} The professional engineering license is modeled using the `identity` pallet. This pallet allows a user to put forth a proposed identity and ask for a review by any number of registrars. ![Example Identity Records Representing a Professional and their Active Licensure Authority](https://3053091312-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3UKO6MPPEQpqMJk5aWx1%2Fuploads%2FWh7l8cI7lWdCci9NBJO1%2Fimage.png?alt=media\&token=905d093d-c1ad-4cf6-b489-cac7d134aef5) {% hint style="info" %} ## License Application and Issuance An engineering board of directors may become a registrar on the network. Adding registrars are currently done through the master admin (sudo); but will eventually be converted to a council decision. Registrar has the authority to review the identity and validate it. A user may assign an identity to their prime account which would represent their main user information (name, email, etc). When applying for a license, a user creates an account and adds it as a sub-account. The user then submits the sub-account to the board to make a judgment (approve) the identity. The board can change the state of the identity. Once the license (sub identity) is approved, the engineer uses this license address to seal drawings. {% endhint %} ## Professional Supervision Record {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/contracts" %} [contracts](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/contracts) {% endcontent-ref %} The `contracts` pallet allows for the distribution of generic smart contracts which deploy into the blockchain and represent the professional interactions for each licensed activity on the network. {% hint style="warning" %} ## Construction Document Records ### Minimum Required Specification Each professional enters into a `Contract of Supervision` when they begin working on a project. This connects the licensed agents to the record of supervision for the project. #### Deploying Contract Because many jurisdictions require both the firm and the individual to be licensed, this contract may require authorization by both licensed parties: the `firm` and the `individual`. Each individually permitted document should be deployed as a separate contract. #### Description of Supervision This `Contract of Supervision` should also store the state of the work contract including * `deliverables` - the list of deliverables and their state (percent completion). * `discipline` - the discipline associated with the supervision (elec, mech, etc) * `standard_of_care` - the standard of care implemented for the supervision #### Record of Work * For the sake of practical implementation, we will limit the record of work to any substantial deliverable sent from professional outward which would increase the amount of completed effort by a minimum of 10 percent. * The `Record of Work` is a record of all major deliverable points, who performed the design, who checked the work, and who verified proof of the standard of care for the block entry. * For each record of work parties sign: * the designer submits work for review under a `Minimum Standard of Care` `Configuration Trait` * a reviewer checks work against the`Minimum Standard of Care` `Configuration Trait` * the professional signs that the document has been designed and backchecked per the `Standard of Care` ### Proposed Future Specification #### Record of Payment The contact may also be capable of recording payment history and terms. In the event of payment default, the contract would set the state of record drawings to `invalid` thereby prohibiting continued use of the construction documents (ie they would no longer be permitted for use in construction. #### Handling Payment Defaults In the event of default, any queries to construction document status would * return an Error: Invalid Contract, Payment Default. NOT FOR CONSTRUCTION and * the contract would also engage the IPFS storage utility to encrypt the data to prevent further download until payment is remedied. {% endhint %} {% hint style="danger" %} ## Construction Document Records ### Proposed Future Specification #### Record of Payment The contact may also be capable of recording payment history and terms. In the event of payment default, the contract would set the state of record drawings to `invalid` thereby prohibiting continued use of the construction documents (ie they would no longer be permitted for use in construction. #### Handling Payment Defaults In the event of default, any queries to construction document status would * return an Error: Invalid Contract, Payment Default. NOT FOR CONSTRUCTION and * the contract would also engage the IPFS storage utility to encrypt the data to prevent further download until payment is remedied. {% endhint %} ## Off-Chain Worker {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/off-chain-worker" %} [off-chain-worker](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/off-chain-worker) {% endcontent-ref %} {% hint style="warning" %} ### Verify Document Authenticity A user submits files (or links to files) to check their authenticity. The off-chain worker downloads the file, hashes and compares it to the state on contract, and emits and `Event` describes the findings. {% endhint %} [Documentation](https://docs.substrate.io/how-to-guides/v3/ocw/local-storage/) on how to implement. ## Cross-Discipline Authorization {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/multisig" %} [multisig](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/multisig) {% endcontent-ref %} Creates an origin that requires multiple parties to sign before authorizing a transaction. {% hint style="info" %} ### Project Kick-Off Kicking off a project may require a signature from the sales member as well as from the tehcnical director confirming all requirements are met for kicking the project off. {% endhint %} ## Offenses {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/offences" %} [offences](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/offences) {% endcontent-ref %} This pallet tracks the reported offenses. {% hint style="warning" %} ### Disciplinary Action by Board of Directors A supervisory board regulating some issued credentials could submit disciplinary action against the `Validator` in accordance with their own regulations. {% endhint %} {% hint style="warning" %} ### Failure to Comply to Standard of Care The community itself could check on the implemented standards of care and any violation would be reported as an `Offense`. *example: PermitZIP requires checklists as part of the process for every project, every deliverable. If the reviewer `Validated` a design without completing the checklist, this would be an `Offence`.* {% endhint %} ## Recovering Lost of Stolen Licenses {% content-ref url="../../developers/notes-about-substrate/prebuilt-pallets/recovery" %} [recovery](https://www.build3.network/developers/notes-about-substrate/prebuilt-pallets/recovery) {% endcontent-ref %} Allows account recovery if lost credentials based on M-of-N social recovery. {% hint style="warning" %} ### Stolen Professional License When a license is lost or stolen, this `Pallet` provides for a means of recovery which also secures the license. #### Recovery Process The recovery process is protected by trusted "friends" and a specific threshold of that list is required to recover. This helps to address the idea of an engineer losing "control" of their license. * the board could temporarily `lock` the license * any use of an illegal or invalidated license would notify the board * the engineer could go through the recovery process, and notify the board when recovered * when the account is recovered, the engineer can request it to be re-authorized (paying board fees as needed) {% endhint %} ## --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.build3.network/researchers/use-cases/proof-of-supervision-with-blockchain.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.