# Nullify **セキュア。透過的。Nullified。** Nullifyは、オープンソースでモジュール式のデータ保持・削除・ライフサイクルガバナンスプラットフォームです。分散したデータ環境全体で、データの検出、保持ポリシーの評価、制御されたライフサイクルアクションの実行、検証可能な監査記録の維持を行うための集中型フレームワークを提供します。 Nullifyは、仕様第一のアーキテクチャを中心に設計されています。中核モジュールはデータライフサイクルガバナンスに必要な基盤機能を提供し、オプションのプラグインモジュールは、追加のコネクタ、コンプライアンスフレームワーク、インテリジェンス、統合、ストレージシステム、デプロイ機能によってNullifyを拡張します。 ## 仕様 Nullifyは、集中型データライフサイクル管理のためのオープンソースアーキテクチャを定義します。 この仕様は、いくつかの原則に基づいて構築されています。 - 集中型ポリシー調整 - 分散データソースのサポート - ポリシー駆動型の保持と削除 - 明示的な承認と認可 - ドライランおよび検証ワークフロー - 不変かつ検証可能な監査 - データ系統と来歴 - モジュール式コネクタと統合 - 破壊的操作に対する人間による監督 - デフォルトでセキュアな実行 - ベンダーニュートラルなアーキテクチャ - ローカル、クラウド、ハイブリッド、フェデレーション型デプロイ - 拡張可能なプラグインアーキテクチャ - 透過的なポリシー評価 - 再現可能なライフサイクル決定 Nullifyは、組織がデータを独自の集中型リポジトリに移行することを要求しません。代わりに、このシステムは既存のデータ環境全体でライフサイクルポリシーとアクションを調整します。 ## アーキテクチャ Nullifyは、2つの主要なアーキテクチャ層に分かれています。 1. コアモジュール 2. オプションのプラグインモジュール コアモジュールには、Nullifyを運用するために必要な基盤機能が含まれています。オプションのプラグインは、ベースプラットフォームを特定のデータベース、クラウドプロバイダー、コンプライアンスフレームワーク、AIシステム、通知プラットフォーム、またはインフラストラクチャ環境に依存させることなく、専門的な機能を提供します。 ### コアアーキテクチャ 主要なライフサイクルフローは次のとおりです。 **発見 → 分類 → ポリシー評価 → 承認 → スケジューリング → 実行 → 検証 → 監査** 各ステージは、独立して保守可能なコアモジュールによって表されます。 ## コアモジュール ### 1. データ発見モジュール データ発見モジュールは、Nullifyによって管理されるデータリソースを識別し、インベントリ化します。 機能は次のとおりです。 - データソースの登録 - リソースの発見 - データセットとオブジェクトのインベントリ - メタデータの収集 - データ所有権メタデータ - 作成および変更タイムスタンプ - アクセスメタデータ - ストレージロケーションの追跡 - リソースステータスの追跡 - データソースのヘルスモニタリング - 発見スケジューリング このモジュールは、基盤となるデータをNullifyにコピーすることを要求せずに、下流のライフサイクルポリシーに必要なインベントリを提供します。 ### 2. データ分類モジュール データ分類モジュールは、発見されたリソースに構造化されたメタデータを割り当てます。 機能は次のとおりです。 - データカテゴリの割り当て - 機密性の分類 - PII分類 - 財務データの分類 - 健康データの分類 - 内部および公開の分類 - ユーザー定義の分類 - 分類の信頼度 - 分類履歴 - 手動分類 - 分類の上書き 分類結果は、ポリシー評価プロセスへの入力になります。 ### 3. ポリシーエンジンモジュール ポリシーエンジンは、Nullifyの中央意思決定コンポーネントです。 機能は次のとおりです。 - 保持ポリシー - 削除ポリシー - アーカイブポリシー - 匿名化ポリシー - リーガルホールド規則 - 例外規則 - ポリシーの優先順位 - ポリシーの継承 - ポリシーのバージョニング - ポリシーの有効化と失効 - ポリシーのシミュレーション - ポリシーの競合検出 - ポリシーの検証 - ポリシーのロールバック ポリシーは宣言的で機械可読であるべきです。 Nullifyは、正規化された内部ポリシーモデルを維持しながら、複数のポリシー形式をサポートする必要があります。 ### 4. ライフサイクル決定モジュール ライフサイクル決定モジュールは、ポリシー評価を明示的なライフサイクル決定に変換します。 サポートされる決定は次のとおりです。 - 保持 - レビュー - アーカイブ - 匿名化 - 削除 - リーガルホールド - 例外 - 延期 すべての決定には、次のことを説明するのに十分なメタデータが含まれている必要があります。 - どのような決定が行われたか - どのリソースが影響を受けたか - どのポリシーが決定を生成したか - どのポリシーバージョンが使用されたか - 決定が作成された日時 - 決定が実行されるべき日時 - 承認が必要かどうか ### 5. 承認および人間による監督モジュール Nullifyは、すべての破壊的操作が完全に自動化できることを想定すべきではありません。 承認モジュールは、制御された人間による監督を提供します。 機能は次のとおりです。 - 承認キュー - 複数人による承認 - ロールベースの承認 - 承認の委任 - 承認の有効期限 - 拒否ワークフロー - エスカレーションワークフロー - 緊急ホールド - 手動による上書き - 承認履歴 組織は、どのアクションに人間の承認が必要で、どのアクションが自動的に実行されるかを設定できます。 ### 6. スケジューリングモジュール スケジューリングモジュールは、ライフサイクルアクションがいつ発生するかを管理します。 機能は次のとおりです。 - スケジュールされた削除 - スケジュールされたアーカイブ - スケジュールされた匿名化 - バッチ処理 - 優先度キュー - メンテナンスウィンドウ - リソースを考慮したスケジューリング - 再試行スケジューリング - 依存関係を考慮した実行 - ワークロードバランシング - 実行スロットリング スケジューリングは、アクションを実行するという決定と、そのアクションの実際の実行を分離する必要があります。 ### 7. アクション実行モジュール アクション実行モジュールは、登録されたデータソースに対して承認されたライフサイクル操作を実行します。 サポートされるライフサイクルアクションは次のとおりです。 - 削除 - アーカイブ - 匿名化 - 編集 - 隔離 - 移動 - 失効 - アクセス取り消し 機能は次のとおりです。 - ドライラン実行 - 実行前検証 - 実行確認 - サポートされている場合のトランザクション対応操作 - 再試行処理 - 障害検出 - 部分的な障害の追跡 - 実行ステータス - 実行レシート - 冪等な実行 - 安全な実行制御 破壊的なアクションには、設定されたポリシーに従って明示的な認可が必要です。 ### 8. 検証モジュール 検証モジュールは、ライフサイクルアクションが正常に完了したかどうかを確認します。 機能は次のとおりです。 - 削除の検証 - アーカイブの検証 - 匿名化の検証 - ソースの確認 - レプリカの検証 - 再試行の検証 - 失敗したアクションの検出 - 残余データの検出 - 検証レポート 検証では、次の状態を区別する必要があります。 - 要求済み - 承認済み - スケジュール済み - 実行済み - 検証済み - 失敗 - 部分的に完了 ### 9. 監査および証拠モジュール 監査および証拠モジュールは、すべての重要なシステムアクションの完全なライフサイクルを記録します。 機能は次のとおりです。 - 不変の監査イベント - 暗号化によるイベント整合性 - ポリシー決定記録 - 承認記録 - 実行記録 - 検証記録 - ユーザーアクティビティ記録 - 設定履歴 - ポリシー履歴 - 監査エクスポート - 証拠パッケージ - 保管責任の連鎖記録 監査記録により、ライフサイクル決定が発生した理由とその後の出来事を再構築できるようにする必要があります。 ### 10. データ系統モジュール データ系統モジュールは、データリソース間の関係を追跡します。 機能は次のとおりです。 - ソース系統 - 宛先系統 - 変換系統 - コピー関係 - レプリケーション関係 - 派生データ関係 - 親子関係 - データ移動履歴 - ライフサイクル伝播 系統により、Nullifyは保持、アーカイブ、匿名化、または削除も必要となる可能性のある関連リソースを特定できます。 ### 11. アクセス制御モジュール アクセス制御モジュールは、管理操作およびライフサイクル操作を保護します。 機能は次のとおりです。 - ロールベースアクセス制御 - 属性ベースアクセス制御 - 権限管理 - リソースレベルの権限 - アクションレベルの権限 - 承認権限 - 管理分離 - セッション管理 - 認証統合 - 認可の監査 破壊的操作には、最小権限の認可を使用する必要があります。 ### 12. 通知モジュール 通知モジュールは、システムおよびライフサイクル通知を提供します。 機能は次のとおりです。 - ポリシー違反アラート - 実行失敗アラート - 承認通知 - スケジュール済みアクション通知 - 検証失敗 - データソース障害 - コンプライアンスアラート - 管理通知 コアモジュールは通知インターフェースを公開する必要がありますが、配信メカニズムは交換可能なままにしておく必要があります。 ### 13. APIモジュール APIモジュールは、Nullifyへのプログラムによるアクセスを提供します。 機能は次のとおりです。 - REST API - GraphQL API - 認証 - 認可 - リソース管理 - ポリシー管理 - ライフサイクル管理 - 監査クエリ - レポート - プラグイン管理 - 管理操作 APIは、安定したバージョン管理されたインターフェースを公開する必要があります。 ### 14. ダッシュボードモジュール ダッシュボードは、プライマリ管理インターフェースを提供します。 機能は次のとおりです。 - データインベントリ - 保持ステータス - 保留中のアクション - ポリシーステータス - 承認キュー - 実行ステータス - 検証ステータス - 監査履歴 - ポリシーの競合 - コンプライアンスメトリクス - システムヘルス - プラグインステータス ダッシュボードは、ユーザーが基盤となるデータベースや実行システムと直接やり取りすることを要求せずに、可視性を提供する必要があります。 ### 15. レポートモジュール レポートモジュールは、ライフサイクルデータを運用およびコンプライアンスレポートに変換します。 機能は次のとおりです。 - 保持レポート - 削除レポート - ポリシーレポート - 監査レポート - 例外レポート - リーガルホールドレポート - 実行レポート - 検証レポート - データインベントリレポート - コンプライアンス証拠パッケージ サポートされるエクスポート形式は次のとおりです。 - JSON - CSV - PDF - 構造化された機械可読な証拠形式 ### 16. マルチテナントモジュール マルチテナントモジュールにより、Nullifyは複数の組織環境にわたって動作できます。 機能は次のとおりです。 - 組織の分離 - テナント固有のポリシー - テナント固有の管理者 - テナント固有の監査記録 - テナント固有のコネクタ - テナント固有の保持規則 - テナント固有のレポート - テナントレベルの設定 テナントの境界は、認可層とデータアクセス層で強制される必要があります。 ### 17. フェデレーションモジュール フェデレーションモジュールは、複数のNullifyインストールを調整します。 機能は次のとおりです。 - マルチクラスタ調整 - フェデレーテッドポリシー - 分散実行 - 地域別ライフサイクル強制 - クロス環境監査調整 - 集中型可視性 - ローカル実行 - フェデレーテッド検証 フェデレーションにより、組織はデータに対するローカル制御を維持しながら、ライフサイクルガバナンスを中央で調整できます。 ## オプションのプラグインモジュール プラグインは、コアプラットフォームの依存関係要件を拡張することなくNullifyを拡張します。 プラグインは、文書化されたインターフェースとAPIを使用し、個別にインストール、アップグレード、有効化、無効化が可能である必要があります。 ### データソースプラグイン オプションのコネクタには次のものが含まれる場合があります。 - PostgreSQL - MySQL - MariaDB - Microsoft SQL Server - Oracle Database - MongoDB - Redis - Elasticsearch - OpenSearch - Snowflake - BigQuery - Databricks - Apache Cassandra - S3互換ストレージ - Google Cloud Storage - Azure Blob Storage - ネットワークファイルシステム - オブジェクトストレージシステム - カスタムREST API ### クラウドプロバイダープラグイン オプションの統合には次のものが含まれる場合があります。 - AWS - Microsoft Azure - Google Cloud - Cloudflare - DigitalOcean - その他のS3互換インフラストラクチャ クラウドプラグインはオプションのままであり、Nullifyがベンダーニュートラルであることを維持する必要があります。 ### コンプライアンスプラグイン オプションのコンプライアンスポリシーパックには次のものが含まれる場合があります。 - GDPR - CCPA - CPRA - HIPAA - GLBA - FERPA - PCI DSS - SOX - 地域のプライバシー要件 - 組織固有のコンプライアンスフレームワーク コンプライアンスプラグインは、規制要件をコアエンジンにハードコードするのではなく、ポリシーテンプレートとマッピングを提供する必要があります。 ### AIおよびインテリジェンスプラグイン AI機能はオプションのままにしておく必要があります。 可能なプラグインは次のとおりです。 - 機密データの分類 - PII検出 - ドキュメント分類 - エンティティ認識 - 保持レコメンデーション - ポリシー競合分析 - ポリシー最適化 - 異常検出 - 削除失敗分析 - コンプライアンス支援 - 自然言語によるポリシー作成 AI生成のレコメンデーションは、ポリシー制御と人間による監督の対象であり続ける必要があります。 ### ワークフロープラグイン オプションのワークフロー統合には次のものが含まれる場合があります。 - Apache Airflow - Dagster - Temporal - Kubernetes Jobs - GitLab CI/CD - その他のワークフローオーケストレーションプラットフォーム ### イベントバスプラグイン オプションのイベント統合には次のものが含まれる場合があります。 - Apache Kafka - RabbitMQ - NATS - Redis Streams - MQTT - クラウドイベントシステム ### IDプラグイン オプションの認証およびID統合には次のものが含まれる場合があります。 - LDAP - Active Directory - OAuth - OpenID Connect - SAML - エンタープライズIDプロバイダー ### 通知プラグイン オプションの通知統合には次のものが含まれる場合があります。 - Email - Slack - Microsoft Teams - Webhooks - PagerDuty - その他の通知サービス ### ストレージプラグイン Nullifyは、監査記録、証拠、メタデータ、システム状態のためにオプションのストレージバックエンドをサポートする場合があります。 可能なプラグインは次のとおりです。 - PostgreSQL - SQLite - MariaDB - S3互換オブジェクトストレージ - MinIO - 分散データベース - エンタープライズストレージシステム ### デプロイプラグイン オプションのデプロイモジュールは、以下を提供する場合があります。 - Docker - Docker Compose - Kubernetes - Helm - Terraform - Ansible - クラウドデプロイテンプレート ## セキュリティアーキテクチャ セキュリティは、オプションのプラグインではなく中核的な要件です。 Nullifyは以下を提供する必要があります。 - 転送中の暗号化 - 保存時の暗号化 - 最小権限の認可 - 安全な資格情報の取り扱い - シークレット管理統合 - 認証 - 認可 - 監査ログ - 暗号化による監査整合性 - レート制限 - APIセキュリティ - 管理分離 - 安全なプラグイン分離 - 設定検証 - 安全なデフォルト Nullifyは、アプリケーション設定に平文の資格情報を保存することを決して要求してはなりません。 ## 安全な削除アーキテクチャ 削除は潜在的に破壊的であるため、Nullifyはライフサイクル決定を実行から分離します。 推奨されるライフサイクルは次のとおりです。 1. リソースを発見する 2. リソースを分類する 3. 適用可能なポリシーを評価する 4. ライフサイクル決定を生成する 5. 例外とリーガルホールドを確認する 6. 必要な場合は承認を要求する 7. アクションをスケジュールする 8. アクションを実行する 9. 結果を検証する 10. 証拠を記録する 11. ライフサイクル状態を更新する 12. 結果を報告する ドライランモードにより、組織は破壊的なアクションを実行する前に期待される結果を評価できます。 ## リーガルホールドと例外 Nullifyは、自動削除を防ぐライフサイクル例外をサポートする必要があります。 例は次のとおりです。 - リーガルホールド - 調査 - 進行中の紛争 - 規制上の保存要件 - セキュリティ調査 - 組織上の例外 - 一時的な保持延長 リーガルホールドまたは承認された例外は、設定されたポリシー階層に従って、通常の削除ポリシーよりも優先される必要があります。 ## ポリシー競合検出 Nullifyは、ポリシーが競合するライフサイクル決定を生成する状況を特定する必要があります。 例は次のとおりです。 - 削除と保持 - 削除とリーガルホールド - アーカイブと削除 - 競合する保持期間 - 競合する組織ポリシー - 競合する管轄区域ポリシー システムは競合を説明し、それに寄与したポリシーを特定する必要があります。 ## 透明性 すべての重要なライフサイクル決定は説明可能である必要があります。 Nullifyは、以下を含む決定記録を提供する必要があります。 - リソース - データ分類 - 適用可能なポリシー - ポリシーバージョン - ポリシー評価 - 例外 - 承認要件 - 最終決定 - 実行ステータス - 検証ステータス - 関連する監査イベント これにより、ポリシー定義からライフサイクル結果までの監査可能なチェーンが作成されます。 ## テクノロジーアーキテクチャ Nullifyは、仕様レベルでテクノロジー中立性を維持するように設計されています。 リファレンス実装では、以下を使用する場合があります。 - Python - FastAPI - React - PostgreSQL - Open Policy Agent - Apache Airflow - Dagster - Docker - Kubernetes - MinIO - Apache Kafka - RabbitMQ - NATS これらのテクノロジーは、Nullify仕様の必須要件ではなく、実装の選択肢です。 ## モジュール設計 Nullifyはモジュール式アーキテクチャに従うため、組織は必要な機能のみをデプロイできます。 コアプラットフォームは以下を提供する必要があります。 - 発見 - 分類 - ポリシー評価 - ライフサイクル決定 - 承認 - スケジューリング - 実行 - 検証 - 監査 - 系統 - アクセス制御 - 通知 - API - ダッシュボード - レポート - マルチテナンシー - フェデレーション オプション機能は、プラグインを通じて提供される必要があります。 このアーキテクチャにより、コアプラットフォームが特定のベンダー、クラウドプロバイダー、データベース、AIシステム、コンプライアンスフレームワーク、またはインフラストラクチャプラットフォームに密結合することを防ぎます。 ## プラグイン要件 プラグインは次のことを行う必要があります。 - 文書化されたインターフェースを使用する - 独立した設定を維持する - 依存関係を宣言する - ヘルスチェックを提供する - 有効化および無効化操作をサポートする - 明確なエラーレポートを提供する - Nullifyの認可を尊重する - 適切な監査イベントを発行する - コアポリシー評価を迂回しない - サポートされているAPIバージョンとの互換性を維持する - ドキュメントを含める - テストを含める プラグインは、ライフサイクルポリシーまたは認可制御を回避してはなりません。 ## 可観測性 Nullifyは、以下に関する運用テレメトリを公開する必要があります。 - データ発見 - ポリシー評価 - キューの深さ - スケジュール済みアクション - 実行パフォーマンス - 実行失敗 - 検証失敗 - APIパフォーマンス - プラグインヘルス - データソースヘルス - システムヘルス オプションの可観測性プラグインは、外部の監視およびロギングプラットフォームと統合する場合があります。 ## 信頼性 Nullifyは以下をサポートする必要があります。 - 再試行 - 冪等なアクション - 障害回復 - キューの永続化 - 実行チェックポイント - ヘルスチェック - サービスリカバリ - バックアップとリストア - ディザスタリカバリ - 部分的な障害の処理 失敗した削除が成功として黙って報告されることは決してあってはなりません。 ## デプロイモデル Nullifyは以下をサポートする必要があります。 - ローカル開発 - シングルサーバーデプロイ - Dockerデプロイ - Kubernetesデプロイ - オンプレミスデプロイ - クラウドデプロイ - ハイブリッドデプロイ - マルチリージョンデプロイ - フェデレーテッドデプロイ 組織は、独自のホステッドサービスに依存せずにNullifyを運用できる必要があります。 ## 機能ロードマップ ### コア - [ ] データ発見 - [ ] データ分類 - [ ] ポリシーエンジン - [ ] ライフサイクル決定 - [ ] 承認ワークフロー - [ ] スケジューリング - [ ] アクション実行 - [ ] ドライランモード - [ ] 実行検証 - [ ] 監査と証拠 - [ ] データ系統 - [ ] RBAC - [ ] ABAC - [ ] 通知 - [ ] REST API - [ ] GraphQL API - [ ] ダッシュボード - [ ] レポート - [ ] マルチテナンシー - [ ] フェデレーション ### セキュリティ - [ ] 転送中の暗号化 - [ ] 保存時の暗号化 - [ ] 安全な資格情報管理 - [ ] シークレット管理統合 - [ ] 暗号化による監査整合性 - [ ] 最小権限の認可 - [ ] 管理分離 - [ ] 安全なプラグインアーキテクチャ ### ガバナンス - [ ] ポリシーバージョニング - [ ] ポリシーロールバック - [ ] ポリシーシミュレーション - [ ] ポリシー競合検出 - [ ] リーガルホールド - [ ] ライフサイクル例外 - [ ] ポリシーの優先順位 - [ ] 保持レコメンデーション - [ ] コンプライアンスレポート ### 信頼性 - [ ] 冪等な実行 - [ ] 再試行管理 - [ ] 障害回復 - [ ] 実行チェックポイント - [ ] ヘルスモニタリング - [ ] バックアップとリストア - [ ] ディザスタリカバリ ### オプションプラグイン- [ ] SQLコネクタ - [ ] NoSQLコネクタ - [ ] オブジェクトストレージコネクタ - [ ] クラウドプロバイダーコネクタ - [ ] コンプライアンスポリシーパック - [ ] AI分類 - [ ] AIコンプライアンスアドバイザー - [ ] ワークフロー統合 - [ ] イベントバス統合 - [ ] アイデンティティ統合 - [ ] 通知統合 - [ ] 可観測性統合 - [ ] 追加のストレージバックエンド - [ ] デプロイメント統合 --- ## オープンソース開発 Nullifyは、コミュニティ主導のオープンソースプロジェクトとして開発されることを意図しています。 貢献者は以下の方法で参加できます: - コアモジュールの開発 - プラグインの作成 - コネクタの構築 - ポリシーパックの作成 - ドキュメントの改善 - テストの作成 - バグの報告 - セキュリティの向上 - 統合の開発 - 仕様改善の提案 モジュラーアーキテクチャにより、機能がプラグインとして実装できる場合、貢献者は基盤となるライフサイクルエンジンを変更することなくNullifyを拡張できます。 ## 設計目標 Nullifyは以下を提供するように設計されています: - 不透明なライフサイクル自動化よりも透明性 - 手動プロセスよりもポリシー駆動のガバナンス - モノリシックな依存関係よりもモジュラーアーキテクチャ - プラットフォームロックインよりもベンダーニュートラル - 検証不可能な主張よりも検証可能な証拠 - 制御不能な自動化よりも人間による監視 - プロプライエタリな統合よりもオープンソースの拡張性 - 分散実行を伴う中央集権的なガバナンス - 制御不能な破壊よりも安全な削除 --- ## Specification Branding License (SBL) ### 標準 - AGPL-3.0+ 完全準拠のシステム - ネットワークデプロイメントに対してコピーレフトを適用 - 必須の帰属表示: - Roxanne Ardary - https://www.roxanneardary.com/ ### 任意 - **Specification Branding License (SBL)** - 帰属表示なしの商用デプロイメント - 規模、使用状況、デプロイメント範囲に基づく価格設定 - [https://roxanneardary.com/nullify/](https://roxanneardary.com/nullify/) --- ## 📄 ライセンスと通知要件 **Nullify** は **GNU Affero General Public License v3.0以降 (AGPL-3.0+)** の下でリリースされています。 このプロジェクトに貢献することにより、あなたの貢献もこのライセンスの下でリリースされることに同意したものとみなされます。 以下の点にご注意ください: - すべての貢献は **AGPL-3.0+** の条件に準拠する必要があります。 - ライセンスの**第7条**に基づき、すべての再配布、フォーク、および二次的著作物は、以下の帰属表示を保持する必要があります: **Roxanne Ardary** および **[roxanneardary.com](https://www.roxanneardary.com/)**。 - Nullifyの仕様は、帰属表示付きで自由に使用できます。Specification Branding Licenseは、リクエストに応じて交渉が可能です。 - プロジェクトの **notice.md** ファイルは、帰属要件と貢献者の謝辞を管理します。 新しい貢献者を追加したり、帰属表示を変更する更新は、`notice.md` も更新する必要があります。 - プルリクエストを送信する際は、該当する場合、新しいファイルが帰属ヘッダーを維持していることを確認してください。 - このソフトウェアのネットワークデプロイ版も、ライセンスの下で該当する場合のソースコード変更の開示を含め、完全なAGPL-3.0+準拠を維持する必要があります。 完全な法的詳細については、AGPL-3.0+ライセンスおよびプロジェクトの `notice.md` ファイルを参照してください。 **Open Arsenal Hub** [https://gitlab.com/Roxanne_Ardary/open-arsenal-specs](https://gitlab.com/Roxanne_Ardary/open-arsenal-specs)
