@plasius/schema 1.1.0 → 1.2.0

package/.github/workflows/ci.yml

@@ -1,16 +0,0 @@
-name: CI
-on:
-  push: { branches: [main] }
-  pull_request: { branches: [main] }
-jobs:
-  build-test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: "22"
-          cache: "npm"
-      - run: npm ci
-      - run: npm run build
-      - run: npm test

package/.nvmrc

@@ -1 +0,0 @@
-22

package/.vscode/launch.json

@@ -1,15 +0,0 @@
-{
-  "version": "0.2.0",
-  "configurations": [
-    {
-      "type": "node",
-      "request": "launch",
-      "name": "Debug Vitest",
-      "program": "${workspaceFolder}/node_modules/vitest/vitest.mjs",
-      "args": ["run"],
-      "cwd": "${workspaceFolder}",
-      "console": "integratedTerminal",
-      "skipFiles": ["<node_internals>/**"]
-    }
-  ]
-}

package/CHANGELOG.md

@@ -1,120 +0,0 @@
-
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on **[Keep a Changelog](https://keepachangelog.com/en/1.1.0/)**, and this project adheres to **[Semantic Versioning](https://semver.org/spec/v2.0.0.html)**.
-
----
-
-## [Unreleased]
-
-- **Added**
-  - (placeholder)
-
-- **Changed**
-  - (placeholder)
-
-- **Fixed**
-  - (placeholder)
-
-- **Security**
-  - (placeholder)
-
-## [1.1.0] - 2025-09-18
-
-- **Added**
-  - field().upgrade() function now added to allow upgrades of older data sets to newer data.
-  - min/max/pattern/default FieldBuilder elements added for validation.
-  - Added new validator for language code BCP 47 format.
-  - Added new validator options for ISO DATE TIME filtering to Date or Time or Both
-  - Added new pre-built field() types including PII flags and validators for:
-    - email
-    - phone
-    - url
-    - uuid
-    - dateTimeISO
-    - dateISO
-    - timeISO
-    - richText
-    - generalText
-    - latitude
-    - longitude
-    - version
-    - countryCode
-    - languageCode
-  - New field().xxx tests for the above types.
-
-- **Changed**
-  - Updated CD Pipeline to accept a new param for version Major, Minor or Patch update
-
-- **Fixed**
-  - validateISODateTime for dateTime now accepts string matches that might not be the same as the date.toISOString() return value but are still valid ISO Date Time Strings.
-
-- **Security**
-  - (placeholder)
-
-## [1.0.18] - 2025-09-17
-
-- **Fixed**
-  - CD pipeline reorder fix to restore CHANGELOG.md versions
-
-## [1.0.17] - 2025-09-17
-
-- **Added**
-  - chore: Code coverage added
-
-## [1.0.13] - 2025-09-16
-
-- **Changed**
-  - ./src/schema.ts Added comments defining functionality on all externally facing functions.
-
-- **Fixed**
-  - ./src/schema.ts Validation no longer mutates the input, internal system fields are set only on result if not previously present.
-
----
-
-## [1.0.0] - 2025-09-16
-
-- **Added**
-  - Initial public release of `@plasius/schema`.
-  - Fluent field builder API: `field().string().required()`, `field().number().min()`, etc.
-  - Type inference utilities to derive TypeScript types from schema definitions.
-  - Built-in validators for common standards:
-    - ISO-3166 country codes
-    - ISO-4217 currency codes
-    - RFC 5322 email format
-    - E.164 phone format
-    - WHATWG URL format
-    - ISO 8601 date/time
-    - OWASP-guided text/name constraints
-    - UUID (RFC 4122) and SemVer 2.0.0
-  - PII annotations and helpers for redaction/masking before logging.
-  - Lightweight validation runner with success/error result types.
-
-- **Changed**
-  - N/A (initial release)
-
-- **Fixed**
-  - N/A (initial release)
-
----
-
-## Release process (maintainers)
-
-1. Update `CHANGELOG.md` under **Unreleased** with user‑visible changes.
-2. Bump version in `package.json` following SemVer (major/minor/patch).
-3. Move entries from **Unreleased** to a new version section with the current date.
-4. Tag the release in Git (`vX.Y.Z`) and push tags.
-5. Publish to npm (via CI/CD or `npm publish`).
-
-> Tip: Use Conventional Commits in PR titles/bodies to make changelog updates easier.
-
----
-
-[Unreleased]: https://github.com/Plasius-LTD/schema/compare/v1.1.0...HEAD
-[1.0.0]: https://github.com/Plasius-LTD/schema/releases/tag/v1.0.0
-[1.0.13]: https://github.com/Plasius-LTD/schema/releases/tag/v1.0.13
-[1.0.17]: https://github.com/Plasius-LTD/schema/releases/tag/v1.0.17
-[1.0.18]: https://github.com/Plasius-LTD/schema/releases/tag/v1.0.18
-[1.1.0]: https://github.com/Plasius-LTD/schema/releases/tag/v1.1.0

package/CODE_OF_CONDUCT.md

@@ -1,79 +0,0 @@
-# Contributor Covenant Code of Conduct v2.1
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
-
-## Our Standards
-
-Examples of behavior that contributes to a positive environment for our community include:
-
-- Demonstrating empathy and kindness toward other people
-- Being respectful of differing opinions, viewpoints, and experiences
-- Giving and gracefully accepting constructive feedback
-- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
-- Focusing on what is best not just for us as individuals, but for the overall community
-
-Examples of unacceptable behavior include:
-
-- The use of sexualized language or imagery, and sexual attention or advances of any kind
-- Trolling, insulting or derogatory comments, and personal or political attacks
-- Public or private harassment
-- Publishing others’ private information, such as a physical or email address, without their explicit permission
-- Other conduct which could reasonably be considered inappropriate in a professional setting
-
-## Enforcement Responsibilities
-
-Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
-
-Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
-
-## Scope
-
-This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [conduct@plasius.co.uk](mailto:conduct@plasius.co.uk). All complaints will be reviewed and investigated promptly and fairly.
-
-All community leaders are obligated to respect the privacy and security of the reporter of any incident.
-
-## Enforcement Guidelines
-
-Community leaders will follow these Enforcement Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
-
-### 1. Correction
-
-**Community Impact:** Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
-
-**Consequence:** A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
-
-### 2. Warning
-
-**Community Impact:** A violation through a single incident or series of actions.
-
-**Consequence:** A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
-
-### 3. Temporary Ban
-
-**Community Impact:** A serious violation of community standards, including sustained inappropriate behavior.
-
-**Consequence:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
-
-### 4. Permanent Ban
-
-**Community Impact:** Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence:** A permanent ban from any sort of public interaction within the community.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html)
-
-For answers to common questions about this code of conduct, see the [FAQ](https://www.contributor-covenant.org/faq)
-
-[homepage]: [https://www.contributor-covenant.org](https://www.contributor-covenant.org)
-
-If you have any questions or concerns regarding this Code of Conduct, please contact us at [conduct@plasius.co.uk](mailto:conduct@plasius.co.uk).

package/CONTRIBUTING.md

@@ -1,201 +0,0 @@
-# Contributing to @plasius/schema
-
-First off: thanks for taking the time to contribute!
-This document explains how to work on the project, how to propose changes, and what we expect in pull requests.
-
-> TL;DR
->
-> - Be respectful and follow the Code of Conduct.
-> - Open an issue before large changes; small fixes can go straight to a PR.
-> - Write tests, keep coverage steady or improving.
-> - Use Conventional Commits.
-> - Don’t include real PII in code, issues, tests, or logs.
-
----
-
-## Code of Conduct
-
-Participation in this project is governed by our **Code of Conduct** (see `CODE_OF_CONDUCT.md`). By participating, you agree to abide by it.
-
-## Licensing & CLA
-
-This project is open source (see `LICENSE`). To protect contributors and users, we require contributors to agree to our **Contributor License Agreement (CLA)** before we can merge PRs (see `legal/CLA.md`). You’ll be prompted automatically by the CLA bot on your first PR.
-
-> If your company has special legal needs, please contact the maintainers before sending large PRs.
-
-## Security
-
-**Never** report security issues in public issues or PRs. Instead, follow the process in `SECURITY.md`.
-
----
-
-## What this project does
-
-`@plasius/schema` provides a small, strongly-typed schema library:
-
-- A fluent field builder (e.g. `field().string().required()`),
-- Built-in validators for common standards (ISO/RFC/OWASP, etc.),
-- PII annotations + redaction utilities,
-- Type inference for safe, consistent entities across projects.
-
-Contributions typically fall into: new validators, field builder features, type improvements, docs, and tooling quality.
-
----
-
-## Getting started (local dev)
-
-### Prerequisites
-
-- Node.js (use the version specified in `.nvmrc` if present: `nvm use`).
-- npm (we use npm scripts in this repo).
-
-### Install
-
-```bash
-npm ci
-```
-
-### Build
-
-```bash
-npm run build
-```
-
-### Test
-
-```bash
-npm test
-# or, if using Vitest in watch mode
-npm run test:watch
-```
-
-### Lint & format
-
-```bash
-npm run lint
-npm run format
-```
-
-> Tip: set up your editor to run ESLint and Prettier on save.
-
----
-
-## How to propose a change
-
-### 1) For bugs
-
-- Search existing issues first.
-- Open a new issue with:
-  - Clear title, steps to reproduce, expected vs actual behaviour,
-  - Minimal repro (code snippet or small repo),
-  - Environment info (OS, Node, package version).
-
-### 2) For features / refactors
-
-- For anything non-trivial, open an issue first and outline the proposal.
-- If the change affects public API or architecture, add an ADR draft (see `docs/adrs/`).
-
-### 3) Good first issues
-
-We label approachable tasks as **good first issue** and **help wanted**.
-
----
-
-## Branch, commit, PR
-
-**Branching**
-
-- Fork or create a feature branch from `main`: `feat/xyz` or `fix/abc`.
-
-**Commit messages** (Conventional Commits)
-
-- `feat: add ISO-3166 alpha-3 validator`
-- `fix: correct RFC5322 email regex edge-case`
-- `docs: expand PII redaction examples`
-- `refactor: simplify field builder pipeline`
-- `test: add cases for currency code`
-- `chore: bump dev deps`
-
-**Pull Requests**
-
-- Keep PRs focused and small when possible.
-- Include tests for new/changed behaviour.
-- Update docs (README, JSDoc, ADRs) as needed.
-- Add a clear description of what & why, with before/after examples if useful.
-- Ensure CI is green (lint, build, tests).
-
-**PR checklist**
-
-- [ ] Title uses Conventional Commits
-- [ ] Tests added/updated
-- [ ] Lint passes (`npm run lint`)
-- [ ] Build passes (`npm run build`)
-- [ ] Docs updated (README/ADR/CHANGELOG if needed)
-- [ ] No real PII in code, tests, or logs
-
----
-
-## Coding standards
-
-- **Language:** TypeScript with `strict` types.
-- **Style:** ESLint + Prettier.
-- **Tests:** Prefer Vitest (or Jest) + `@testing-library/*` for React-facing bits.
-- **Public API:** Aim for backward compatibility; use SemVer and mark breaking changes clearly (`feat!:` or `fix!:`).
-- **Performance:** Avoid excessive allocations in hot paths; prefer immutable patterns but mind GC pressure.
-- **Docs:** Add TSDoc comments for exported types/functions.
-
-### Validators
-
-- Add tests covering common/edge cases.
-- Cite the source/standard (e.g., ISO/RFC) in comments.
-- Keep regexes readable (use `x`/comments where possible) and benchmark if complex.
-
-### PII handling
-
-- Never include real PII in fixtures or examples.
-- Ensure redaction/cleaning functions operate **before** logging.
-- Add tests confirming no PII leaks to logs or thrown errors.
-
----
-
-## Adding dependencies
-
-- Minimise runtime dependencies; prefer dev dependencies.
-- Justify any new runtime dependency in the PR description (size, security, maintenance).
-- Avoid transitive heavy deps unless critical.
-
----
-
-## Versioning & releases
-
-- We follow **SemVer**.
-- Breaking changes require a major bump and migration notes.
-- Keep the `CHANGELOG.md` (or release notes) clear about user-facing changes.
-
----
-
-## Documentation
-
-- Update `README.md` with new features or setup steps.
-- Add or update ADRs in `docs/adrs/` for architectural decisions.
-- Keep examples minimal, copy-pasteable, and tested when feasible.
-
----
-
-## Maintainers’ process (overview)
-
-- Triage new issues weekly; label and assign.
-- Review PRs for correctness, tests, and docs.
-- Squash-merge with Conventional Commit titles.
-- Publish from CI when applicable.
-
----
-
-## Questions
-
-If you have questions or want feedback before building:
-
-- Open a discussion or issue with a short proposal,
-- Or draft a PR early (mark as **Draft**) to get directional feedback.
-
-Thanks again for contributing 💛

package/CONTRIBUTORS.md

@@ -1,27 +0,0 @@
-# Contributing Guidelines
-
-Thank you for considering contributing to this project! We welcome contributions that improve the code, documentation, and overall project quality.
-
-## Getting Started
-
-- Fork the repository.
-- Create a feature branch from `main`.
-- Commit your changes with clear messages (we follow **Conventional Commits**).
-- Push your branch and open a Pull Request (PR).
-
-## Requirements
-
-- Write tests alongside code where possible.
-- Ensure all tests pass before submitting a PR.
-- Follow the repository’s coding style and linting rules.
-- Update documentation (README, ADRs, etc.) when making significant changes.
-- When making architectural changes, create a new ADR (Architecture Decision Record) that **succeeds** the previous one rather than modifying old ADRs. This preserves history and ensures decisions are traceable.
-- Use the [ADR template](./docs/adrs/adr-template.md) when writing new ADRs to ensure consistency.
-- Before your first contribution, sign the appropriate Contributor License Agreement (CLA). See [legal/CLA.md](legal/CLA.md) for details, then email the signed document to [contributors@plasius.co.uk](mailto:contributors@plasius.co.uk).
-
-## Communication
-
-- Use GitHub Issues for bugs and feature requests.
-- Pull Requests should describe the problem, solution, and trade-offs.
-
-We appreciate your support in making this project better!

package/SECURITY.md

@@ -1,17 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-We currently support the latest major version of this project. Older versions may not receive security updates.
-
-## Reporting a Vulnerability
-
-If you discover a security vulnerability, please report it privately by emailing us at [security@plasius.co.uk](mailto:security@plasius.co.uk). Please do not create a public issue for security-related matters.
-
-## Response Timeline
-
-We aim to acknowledge your report within 2 business days and to provide a more detailed response (including next steps and, if applicable, a timeline for a fix) within 7 business days.
-
-## Disclosure Policy
-
-We request that you give us the opportunity to address the vulnerability before publicly disclosing it. We will coordinate with you on public disclosure once a fix is available and deployed.

package/docs/adrs/adr-0001: schema.md

@@ -1,45 +0,0 @@
-# ADR-0001: Schema Library Purpose and Scope
-
-## Status
-
-- Proposed → Accepted
-- Date: 2025-09-12
-- Version: 1.0
-- Supersedes: N/A
-- Superseded by: N/A
-
-## Context
-
-Managing consistent data structures across a distributed system is difficult. Without a central schema library, each service or package can diverge in how it defines and validates entities, leading to duplication, mismatches, and security gaps (especially around handling Personally Identifiable Information, or PII).
-
-We need a way to:
-
-- Define entities and fields in a consistent, strongly-typed way.
-- Provide validation functions for standard data types and codes (ISO, RFC, OWASP, etc).
-- Support annotation of PII fields so they can be masked or cleaned when logged or transmitted.
-- Offer a foundation that other Plasius packages (e.g. entity-types, state, renderer) can depend upon.
-
-## Decision
-
-We will build a **schema library** (`@plasius/schema`) that:
-
-- Provides a fluent builder API (`field().string().required()` etc.).
-- Exposes reusable validators for standards like ISO-3166 country codes, ISO-4217 currency codes, RFC 5322 emails, etc.
-- Implements utilities for PII handling (masking, redaction).
-- Exports TypeScript types that infer entity structures from schema definitions.
-- Is published as an open source package for transparency and reuse.
-
-## Consequences
-
-- **Positive:** Consistent validation, stronger typing, centralised handling of PII, reduced duplication across Plasius projects, easier onboarding of new developers.
-- **Negative:** Adds a dependency layer that all other packages must import, requiring careful versioning and backward compatibility management.
-- **Neutral:** External adopters may use the library without adopting the full Plasius ecosystem, which is acceptable and encouraged.
-
-## Alternatives Considered
-
-- **Do nothing:** Continue defining ad-hoc validation in each package. (Rejected: inconsistent and unsafe.)
-- **Use an existing library (e.g. Zod, Yup, Joi):** These provide schema validation but lack PII auditing integration and may not align with our field-builder pattern. (Rejected for core use, though we may draw inspiration.)
-
-## References
-
-- [Architectural Decision Records (ADR) standard](https://adr.github.io/)

package/docs/adrs/adr-template.md

@@ -1,67 +0,0 @@
-# Architectural Decision Record (ADR)
-
-## Title
-
-> _Concise, descriptive title of the decision (e.g., “Use Azure Container Apps for n8n Deployment”)_
-
----
-
-## Status
-
-- Proposed | Accepted | Rejected | Superseded | Deprecated
-- Date: YYYY-MM-DD
-- Version: 1.0
-- Supersedes: ADR-XXXX (if applicable)
-- Superseded by: ADR-YYYY (if applicable)
-
----
-
-## Tags
-
-> _Short keywords to help search and group ADRs (e.g., infra, frontend, security, devops, ai, database)._
-
----
-
-## Context
-
-> _Describe the problem we are solving, relevant background, and constraints.  
-> Why are we making this decision? What triggered it?_
-
----
-
-## Decision
-
-> _What is the decision we have made? Clear, affirmative statement of the chosen path._
-
----
-
-## Alternatives Considered
-
-- **Option A**: Description (pros/cons)
-- **Option B**: Description (pros/cons)
-- **Option C**: Description (pros/cons)
-
-> _Why were these alternatives not chosen?_
-
----
-
-## Consequences
-
-- Positive outcomes (benefits, opportunities)
-- Negative outcomes (risks, trade-offs)
-- Any technical debt created or avoided
-- Impact on future decisions
-
----
-
-## Related Decisions
-
-> _Link to related ADRs (if any)_
-
----
-
-## References
-
-- [Architectural Decision Records (ADR) standard](https://adr.github.io/)
-
-> _Links to docs, benchmarks, discussions, or external resources that influenced this decision_

package/legal/CLA-REGISTRY.csv

@@ -1,2 +0,0 @@
-type,github_handle,full_name,company,email,date,approver
-corporate,Zephod111r,Phillip Hounslow,Plasius LTD,zephod@plasius.co.uk,2025-09-12,Phillip Hounslow (Maintainer)

package/legal/CLA.md

@@ -1,22 +0,0 @@
-# Contributor License Agreements (CLA)
-
-To protect the intellectual property of this project and ensure clarity of rights, all contributors must sign a Contributor License Agreement (CLA) before their first contribution.
-
-## Which CLA should I sign?
-
-- **Individual CLA**: If you are contributing personally and not on behalf of an employer, sign the [Individual CLA](INDIVIDUAL_CLA.md).
-- **Corporate CLA**: If you are contributing as part of your work for a company, the company should sign the [Corporate CLA](CORPORATE_CLA.md).
-
-## How to sign
-
-1. Download the appropriate CLA file (Individual or Corporate).
-2. Fill in the required details, sign, and date it.
-3. Email a PDF copy of the signed document to **[contributors@plasius.co.uk](mailto:contributors@plasius.co.uk)** with subject: `CLA – Individual` or `CLA – Corporate`.
-
-## Registry
-
-All signed CLAs are logged internally in the CLA registry (`CLA-REGISTRY.csv`).
-
-## Questions?
-
-If you have any questions about which CLA to sign or how the process works, please email **[contributors@plasius.co.uk](mailtocontributors@plasius.co.uk)**.

package/legal/CORPORATE_CLA.md

@@ -1,57 +0,0 @@
-# Corporate Contributor License Agreement (CLA)
-
-## Purpose
-
-This Corporate Contributor License Agreement ("Agreement") is intended to protect the intellectual property rights of the contributors and the project, ensure clear licensing terms for contributions, and maintain trust within the community. By signing this Agreement, the corporation agrees to the terms that facilitate the use, distribution, and modification of contributions under the project's licensing framework.
-
-## Agreement
-
-1. **Representation of Authority**  
-   The undersigned individual represents and warrants that they have the full legal authority to enter into this Agreement on behalf of the corporation named below ("Corporation") and to grant the rights contained herein.
-
-2. **Grant of Copyright License**  
-   The Corporation hereby grants to the project maintainers and users a perpetual, worldwide, non-exclusive, royalty-free, irrevocable copyright license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute the contributions submitted to the project.
-
-3. **Grant of Patent License**  
-   The Corporation hereby grants to the project maintainers and users a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under any patent claims that are necessarily infringed by the contributions to make, use, sell, offer for sale, import, and otherwise dispose of the contributions or derivative works thereof.
-
-4. **Warranties and Representations**  
-   The Corporation represents and warrants that:
-
-- The contributions are the original work of the Corporation or that the Corporation has sufficient rights to grant the licenses herein.
-- The submission of the contributions does not violate any agreements or rights of third parties.
-
-5. **No Revocation**  
-   This license is granted on a perpetual basis and cannot be revoked, provided that the terms of this Agreement are met.
-
-6. **Governing Law**
-   This Agreement shall be governed by and construed in accordance with the laws of the United Kingdom, without regard to its conflict of laws principles.
-
-7. **Execution**
-
-This Agreement is effective upon signature by the authorized representative of the Corporation. Please sign and date this document, then email a scanned PDF copy to [contributors@plasius.co.uk](mailto:contributors@plasius.co.uk).
-
----
-
-### **@plasius/schema**
-
-**Corporation Legal Name:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
-**Authorized Representative:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
-**Title:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
-**Email:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
-**Date:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
-**Signature:** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
-
----
-
-## How to Sign
-
-- Download this file as a template.
-- Fill in the Corporation’s legal name, authorized representative, title, email, date, and provide a signature.
-- Sign and date the document.
-- Send a scanned copy of the signed Agreement to [contributors@plasius.co.uk](mailto:contributors@plasius.co.uk).