市場調査に戻る
Elixumは、需要、供給、在庫、生産スケジューリング、ネットワークのリスクを扱うサプライチェーン計画スイートAvatarを開発した。計画アプリケーションと、企業間の連携・協業のためのHypertrustプラットフォームを組み合わせている。Elixumは2024年のCamelot買収を通じてAccenture傘下に入った。以前のウェブサイトは現在Accentureへ転送される。本レビューは、保存された技術ページと導入の証拠を用いて、文書化されたAvatarとHypertrustの製品を評価する。 1 2
サプライチェーン総合評価：4.1/10。
| 評価軸 | 点数 |
|---|---|
| サプライチェーンへの深い理解 | 4.4/10 |
| 意思決定と最適化の実質 | 4.4/10 |
| 製品とアーキテクチャの整合性 | 4.6/10 |
| 技術的透明性 | 3.4/10 |
| ベンダーの真摯さ | 3.6/10 |
Avatarは実質的な計画問題に取り組んでいる。スケジューリングの説明には、連結した生産段階、部品の供給可能性、工具、キャンペーン生産、需要と供給の両方に影響する不確実性が含まれる。これらは有用な設計上の約束である。弱点は、その約束と広範な性能主張との距離にある。インメモリのグラフは難しい最適化を瞬時に解けるようにはしないし、確率的方法を挙げても実用的な不確実性の経済モデルが証明されるわけではない。 3 8
製品の大部分は、計画担当者がシナリオを比較し、方針を調整し、例外を解決することを中心に構成されたままである。在庫の分類とDDMRPは、さらにパラメーターの層を加える。Elixumはこの構造内の自動化を説明するが、それによる反復作業の削減、意思決定ロジックの維持費、純経済リターンに関する公開証拠は少ない。独立した製品サイトの撤去により、現在の提供形態とサポートの約束も検証しにくくなっている。 1 5 6 11
ElixumとLokadの比較
何を生産し、どの注文を優先し、どこに在庫を置くかを決める製造業者を考えよう。Avatarは、シナリオ比較と既存システムに接続した計画アプリケーションによって、これらの活動を調整する設定可能なスイートを提供する。供給管理の説明は、集約レベル間で一貫した計画、外部パートナーとの協業、手動計画中の自動的な需給調整を強調する。 4
Lokadの在庫最適化のアプローチは、不確実な需要と供給の下で実行可能な意思決定がもたらす経済的帰結から始まる。反復する意思決定はプログラムによって実行され、専門家はそれを生成する前提とロジックを改善する。Introduction to Supply Chainの視点では、サプライチェーンは意思決定を相互に改善しなければならない経済システムである。
この違いは在庫で特に明確になる。Avatarは方針の分類、バッファー配置、DDMRPの設定を提供する。これらの制御を自動化すれば事務作業は減らせるが、制御自体は経済的に重要なものを間接的に表した中間物であり続ける。ある方針はバッファーの論理を満たしながら、製品間に資金を不適切に割り当てたり、ネットワークの他の場所で利益機会を逃したりしうる。 6
よりよい最適化エンジンを加えるコンサルティング案件は、その後の変更も安価で確実に行えるようにする必要がある。そうでなければ、業務が変わるたびにモデルを保守することで、当初の便益が消費されてしまう。 11
製品の歴史と技術上の約束
| 時期 | 文書化された展開 | 証明されること |
|---|---|---|
| 2018 | Camelotは細胞治療のサプライチェーン向けブロックチェーンシステムとしてHypertrust X-Chainを発売した。別のID管理の発表ではHyperledger IndyとSAP連携を挙げた。 14 15 | ブロックチェーンは、構成要素と用途を明示した実際のプラットフォーム方針だった。 |
| 2018–2020 | Camelot、SAP、Dellの資料は、非公開データのオフチェーン処理と、許可制ブロックチェーンノードおよび任意のトラステッドコンピューティング機器を含むHypertrust参照アーキテクチャを説明した。 16 17 | セキュリティの説明には、ブロックチェーンのプライバシー上の限界への明示的な対応を含む技術開発があった。 |
| 2023 | HypertrustがElixumの子会社となり、既存の契約、窓口、サポートを継続すると発表された。 13 | Avatarと専門的な治療オーケストレーション製品が同じ製品群に入った。 |
| 2024 | AccentureがCamelot買収を完了した。 2 | 所有者は変わったが、買収発表はAvatarの新しい数値アーキテクチャを示していない。 |
| 2025 | Elixumは、生産計画と委託製造業者との調整に関するUroGen Pharma事例を公開した。 12 | 実名顧客が具体的な業務問題に製品を使用していた。 |
| 2026年のレビュー | 現行ドメインはAccentureへ転送される。 1 | 過去の製品文書が、Avatar固有の機構を評価する主な基盤となっている。 |
Hypertrustの歴史には示唆的な緊張関係がある。2020年の参照文書は、選択した情報を共有し、非公開データを処理する仕組みを説明する一方、悪意ある改ざんは不可能だとも主張した。署名付き台帳は記録済み項目の変更を制限できるが、元データを真実にしたり、認証情報の侵害を不可能にしたり、アプリケーションロジックを正しくしたりはできない。技術的な機構には、文書が与えるより精密な主張がふさわしい。 17
その後のAvatarの位置付けも、野心的な技術の約束を繰り返している。生産のページは量子最適化エンジンをGurobiと並べる。どちらの言及も、実証したサプライチェーン処理、実現した優位性、実装状況を示さず、量子という言及を購入者に役立つものにしていない。したがって重要な歴史は、流行語の数だけではない。構成要素やアーキテクチャ上の発想を、優れた成果の広範な約束へ繰り返し引き上げる点である。 8
計画エンジンは実際に何を約束するのか
AvatarのUnified Core Modelは、計画、認知、最適化という三つのエンジンに入力を与える。技術説明はインメモリのグラフとイベントストリーミングを組み合わせ、顧客固有の目的を許し、ソルバーとモデルの選択を提供する。認知エンジンは並列処理のために問題を分解するとも記す。共通表現はデータの変換と同期作業を減らせる。しかし、異なるアルゴリズムが一貫した経済目的を共有することや、分解で失う相互作用を保つことは保証しない。 3
この違いは、分解できない問題でもゼロレイテンシーで計画できるという主張にとって重要である。メモリアクセスとデータベースの構成は、作業の一部にすぎない。相互作用する生産、在庫、調達の判断を選ぶ際には、依然として組合せ探索と不確実な帰結が伴う。現実的な規模でAvatarがその困難にどう対処するかを示す公開処理例はない。 3
生産の製品説明は、より有用な詳細を示す。順序依存の計画、ロットサイズの依存関係、アレルゲンや工具などの属性に基づくキャンペーン生産、資材の供給可能性を扱う。タンクと配管の計画も挙げている。これらの制約は、レイテンシーの主張よりも意図する業務範囲をよく伝える。不足している証拠は、モデルがこれらを共同でどう維持し、利用できる計画を作るためにどの程度の近似を必要とするかに関するものだ。 8
MILPとソルバー連携を、サプライチェーン最適化への完成済みの答えとして提示することは警告信号である。古典的な定式化は、非線形で不連続な商業・業務上の振る舞いを、計算可能な構造へ押し込めなければならない。複製したシナリオで不確実性を追加すると、計算と保守の負担が増える。モデルを小さく分解すれば解けるようになるかもしれないが、その際にシステム全体の最適化を価値あるものにする相互作用そのものを捨てる可能性がある。Avatarは利用可能な手法を説明するが、これらの実用上の限界をどう克服するかは実証していない。 3
中心的な経済の問いも未解決である。供給管理はサービス、レジリエンス、財務、環境の目標を許し、リスク管理は複数の代替目的に対応する。この柔軟性が役立つのは、実装でそれらを調整する費用、便益、拘束力のある制約を示す場合に限られる。サービス点数の改善や在庫量の減少は、それだけでよりよい事業判断にはならない。 4 7
不確実性、デジタルツイン、予測への介入
Avatarは多くの計画スイートより強い不確実性の主張をしている。スケジューリングのページは、動的な許容幅を使って需要と供給の両方の不確実性を伝播させると明記する。リスク管理では、確率計画法、数千の混乱プロファイル、金銭的影響、在庫・能力・調達・輸送接続などの緩和策を説明する。これらは提案手法の重要な要素である。 7 8
公開文書は、確率分布、混乱間の依存関係、校正、動的な許容幅が目的関数にどう入るかを説明しない。日程の周囲に範囲を設けることは、不確実な結果をその経済評価に組み込むことと同じではない。また、シミュレートした混乱に最適化エンジンが反応しても、混乱モデルが業務上の帰結をよく予測する証明にはならない。 7 8
ネットワークのデジタルツインは、将来の意思決定の帰結を推定する際には高次元の予測である。そのため、検証は見栄えのよいネットワーク図を超えなければならない。予測した欠品、遅延、復旧、費用を、その後の業務と比較する必要がある。失敗はモデル改訂につながり、改訂が判断を改善したかを反復可能な試験で確かめるべきである。Avatarのリスク資料は、このフィードバック工程を文書化していない。 7
需要管理には、より明示的なフィードバック機構がある。統計予測と機械学習を組み合わせ、過去の担当者による修正を評価し、反復的な変更を推奨または自動化する。これにより、上書きを自動的に受け入れるのでなく、人の介入を測定可能な試験にかける。しかし、明示する到達点は依然として、より正確な合意計画と効率的な会議である。予測修正の品質は経済成果への入力の一つであり、購買、スケジューリング、在庫配分の品質を証明しない。 5
同じページは短期変化にデマンドセンシングという語を使うが、追加の手法や評価を示さない。データ、予測期間、比較基準、結果としての意思決定が明確になるまで、その名称が加えるものは少ない。このページに、追加した層が経済的成果を改善するかを判断できる数値的な精度主張はない。 5
設定の保守と生産性
Avatarの在庫文書は、自動パラメーター設定の背後に残る作業を明らかにする。DDMRPには、デカップリングポイント、平均日次使用量の算出方法、注文急増のしきい値と期間、分類、プロファイルの割り当てがある。利用者は変更をシミュレートし、推奨を受けられる。プロセスマイニングは手動上書きや未更新のパラメーターも見つける。これらは設定作業を管理する具体的な試みだが、誰かが理解して保守しなければならない大量の設定を維持する。 6
所有コストには、こうしたパラメーター間の相互作用が含まれる。新しい製品群、供給業者の行動変化、商業上の優先順位の変更は、提案値を受け入れる以上の作業を要求しうる。実装では、どの方針がなぜ変わり、その複合効果がシステムを改善したかを確かめなければならない。自動クラスタリングは、その経済的な説明を提供しない。
Elixumのサービスは、設計、設定、稼働開始、初期の集中支援、継続改善、展開、変更管理を含む。アカデミーは利用者と開発者の双方を対象とする。継続的な専門家の作業を伴う提供モデルである。公開された内容は、顧客、ベンダー、パートナーの各チームへの労力配分も、導入後にその労力が減っていく測定済みの推移も示さない。 11
UroGen事例は具体的な利点を示す。ERPに直接アクセスせず委託製造の注文を追跡し、部品の供給可能性を見やすくし、遅延の影響を計算し、実際の生産歩留まりの入力を簡単にすることだ。報告は調整の摩擦軽減を説明するが、前後の労働時間、在庫投資、純金銭リターンは示さない。実証された用途は、業務を担う計画担当者への支援である。 12
ソフトウェアエージェントが定型分析の費用を下げるほど、この区別は重要になる。スイートの持続的な価値には、よりよい意思決定と、それを改善する労力の削減が含まれなければならない。ホリミゼーションの観点では、試されるのは改善サイクル全体である。業務上の失敗を調べ、前提やロジックを変更し、意思決定を再実行し、帰結を確認して修正をリリースする。サービスの説明は、このサイクルの費用と信頼性を定量化していない。 11
ソフトウェア構成部品表
公開された技術説明は、製品群の具体的な構成要素をいくつか特定する。AvatarとHypertrustのフロントエンド開発者は、AngularとTypeScriptの画面、RxJS、再利用可能なPrimeNGコンポーネント、Jestテスト、Dockerに格納したLoopBackのbackend-for-frontendを説明する。Hypertrust X-Chainのバックエンド開発者は、Node.js/TypeScriptサービス、JSONataのレポート、アクセス制御のためのMongoDB集約、GitLab/Dockerによる配信パイプラインを説明する。これらは各職務に固有の、実際の製品開発についての記述である。 18 19
旧来の治療オーケストレーションのアーキテクチャは、別の配置層を加える。2020年の参照資料は、SAP Cloud Platformサービス、Hyperledger Fabricノード、Cloud Foundryで稼働するアプリケーション構成要素、非公開処理向けの任意のローカルインフラを指定する。 17
保守負担はインターフェースから生じる。ブラウザー部品、アプリケーションサービス、グラフベースの計画、ソルバーモデル、顧客連携、そして該当するHypertrust導入での分散ノードである。各境界には、更新、認可規則、データの意味、障害処理が伴う。プラットフォームの費用上の説明は、標準化した部品とインフラの移植性に依拠する。その主張を評価するのに必要な部品バージョン、配置構成、運用費用は公開していない。 9
このアーキテクチャの整合性を保つには、独自拡張の互換性契約と、アプリケーションの進化に合わせた移行手順が必要である。どちらも配置の説明とともには公開されていない。 9
セキュリティと拡張の境界
Hypertrustの過去のセキュリティ設計には実際の機構がある。SAPが公開する2018年の発表資料は、非公開入力をオフチェーンに保ち、ハッシュを記録し、合意した計算を分散させ、参加者が別の実行ファイルに置き換えるのをトラステッドコンピューティングで防ぐ。特定の脅威に対応している。すなわち、基礎となる非公開データを全参加者へ渡さずに、共有結果を計算することである。 16
この限定的な機構は、計画プラットフォーム全体を安全にするものではない。顧客の拡張はアプリケーションロジックを変え、モデルを追加できる。また、プラットフォームは下位のソフトウェア層へのアクセスも推奨する。文書は、こうした拡張の実行時境界を示さない。アクセスできるデータと認証情報、外向き通信の制限の有無、依存関係の承認方法、本番実行の隔離方法が不明である。 9 1
計画の拡張は、商業上機微なデータや業務上の操作の近くに位置しうるため、これは重大な欠落である。侵害された依存部品や偶発的な認証情報の漏えいは、意図した業務フローを迂回しうる。インフラの移植性、コンフィデンシャルコンピューティング、共通データモデルは、明確に強制される実行境界を代替しない。
企業ネットワークの説明は、参加者が情報を共有する相手を選ぶと明記する。有用な方針の考え方である。完全な実装説明なら、派生データ、ログ、バックアップ、独自計算、権限撤回にわたってそれをどう維持するかを示すはずだ。公開説明は、その機構に達する前に終わっている。 10
成果と責任
過去の最も強い数値成果は2020年のHypertrust参照文書にある。概念実証によって、生産サイクルの往復時間を最大25%減らしたとされる。その範囲は重要である。参加者名、総費用、比較できるAvatarの最適化成果を伴わないオーケストレーションの試験だ。UroGen事例は実名で業務内容も具体的だが、定性的である。これらの資料は有用な業務フローアプリケーションを裏付ける一方、純経済リターンは確立していない。 17 12
Elixumの導入サービスは、ソフトウェアと設定作業の両方を対象とする。したがって経済的な責任は、アプリケーションが動くか、利用者が研修を終えたかにとどまらず、結果としての意思決定工程を対象にすべきである。公開サービス資料は、基準状態、実際の意思決定品質の検証、経済的に不適切なモデルを修正する責任を定義していない。このため、低いTCOを訴える位置付けと、導入後に評価できる約束との間に大きな隔たりが残る。 11 1
サプライチェーン評価
各評価軸は、同じ重みの五つの基準の算術平均である。総合評価は全25基準の平均を小数第一位に丸めたものだ。評価対象は、文書化されたAvatarとHypertrustの提供内容である。独立サイトは現在の製品版や商業条件を示さなくなっている。
サプライチェーンへの深い理解
| 評価基準 | 点数 |
|---|---|
| 経済的な問題設定 | 5/10 |
| 具体的な意思決定への到達 | 5/10 |
| サプライチェーンに関する概念の明晰さ | 5/10 |
| 時代遅れの中心的教義からの独立 | 3/10 |
| KPIの見せかけに対する耐性 | 4/10 |
平均：4.4/10。
経済的な問題設定 — 5/10。 金銭的帰結はサービスやリスクの目的と並んで現れる。実装では、これらの指標を一貫した経済的な意思決定基盤に調整する必要が残る。 4 7
具体的な意思決定への到達 — 5/10。 スイートは業務計画とスケジューリングに達している。公開例は担当者の支援と調整を強調し、無人実行やアプリケーション外に残る作業についての証拠は少ない。 8 12
サプライチェーンに関する概念の明晰さ — 5/10。 詳細な制約とサプライチェーンの両側の不確実性を認識している。公開手法は、それらの相互作用が異なるエンジン間で経済的に一貫し続ける仕組みを説明していない。 3 8
時代遅れの中心的教義からの独立 — 3/10。 合意型の計画とDDMRPは依然として中心的である。自動化はその管理を改善するが、こうした中間目標が希少資源を配分する適切な方法であるとは証明していない。 5 6
KPIの見せかけに対する耐性 — 4/10。 説明には実用的な機構と顧客での作業が含まれる。広範なレイテンシーと低費用の主張は、意思決定品質や所有コストの公開測定を今なお上回る。 1 3 12
意思決定と最適化の実質
| 評価基準 | 点数 |
|---|---|
| 確率的モデル化の深さ | 4/10 |
| 最適化または機械学習における独自の実質 | 4/10 |
| 現実の制約への対応 | 6/10 |
| 意思決定の自動化と労働生産性 | 4/10 |
| 実際の業務の複雑性に対する適応力 | 4/10 |
平均：4.4/10。
確率的モデル化の深さ — 4/10。 供給の不確実性を明示的に含む。分布、依存関係の前提、校正、目的の意味が不足し、結果としての意思決定をより高く評価できない。 7 8
最適化または機械学習における独自の実質 — 4/10。 複数の数値手法を特定しているが、その組み合わせ自体が難しい技術課題である。説明は、それによる計算とモデル化の負担に対する独自の解決を示していない。 3
現実の制約への対応 — 6/10。 スケジューリングの範囲は、製造の重要な複雑さを反映する。共同の実行可能性や、不確実性の下で使う近似についての証拠は限られる。 8
意思決定の自動化と労働生産性 — 4/10。 一部の反復調整は学習して自動化できる。より広い作業工程は、シナリオ検討、設定、例外に依存し続け、全当事者の労働削減を測定したものはない。 5 6 11
実際の業務の複雑性に対する適応力 — 4/10。 ストレステストは混乱への露出に対応する。適応力には、業務上の失敗から学び、意思決定モデルを改訂し、経済面から再試験することも必要だが、その改善ループは文書化されていない。 7 11
製品とアーキテクチャの整合性
| 評価基準 | 点数 |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真摯な取り組み | 4/10 |
| ソフトウェアの簡素さと所有コスト | 3/10 |
| プログラム操作とエージェント支援業務との適合性 | 4/10 |
平均：4.6/10。
アーキテクチャの整合性 — 6/10。 設計はデータ表現の重複を制限する。その成功は、独自拡張と混在する数値手法の間で、一貫した意味を保てるかに依存する。 3
システム境界の明確さ — 6/10。 製品は概して企業システムを補完し、外部の当事者を調整する。具体的な顧客利用は、顧客のERPで得られない情報を扱う有用な境界を示す。 9 12
セキュリティへの真摯な取り組み — 4/10。 過去の非公開計算の設計は、特定可能な脅威に対応する。顧客が開発する計画コードの権限と隔離は十分に規定されていない。 16 9
ソフトウェアの簡素さと所有コスト — 3/10。 再利用可能な部品と共有モデルは重複を減らせる。独自ロジック、配置の選択肢、連携サービスは、公開費用モデルがないまま大きな保守義務を生む。 9 11 18
プログラム操作とエージェント支援業務との適合性 — 4/10。 拡張性はプログラムによる作業を許すが、実用的なエージェント型改善工程には反復可能な試験、管理されたリリース、測定可能な介入削減も必要である。これらは公開証拠から確認できない。 3 11
技術的透明性
| 評価基準 | 点数 |
|---|---|
| 公開技術文書 | 4/10 |
| ベンダーを介さずに検証できる度合い | 3/10 |
| 移植性と囲い込みの可視性 | 3/10 |
| 導入方法の透明性 | 4/10 |
| 技術的主張を支える証拠の密度 | 3/10 |
平均：3.4/10。
公開技術文書 — 4/10。 保存されたページと参照設計は、製品の標語以上のものを明らかにする。現在の独立した文書は後退し、計画モデルは依然として十分に規定されていない。 1 3 16
ベンダーを介さずに検証できる度合い — 3/10。 アーキテクチャの説明は調べられるが、主要な数値主張を独立試験できる、動作する公開モデルはない。 3 7
移植性と囲い込みの可視性 — 3/10。 インフラ選択は明示される。結果としての業務ロジック、設定、意思決定履歴を別製品へ移すことは、公開手順のない別の問題である。 9
導入方法の透明性 — 4/10。 サービス一覧は段階と継続作業を示す。受入基準、保守労力、その後のモデル修正への責任は、はるかに不明確である。 11
技術的主張を支える証拠の密度 — 3/10。 具体的な導入詳細と、裏付けのない卓越した性能主張が併存する。報告された成果は、より広い最適化の提案を検証するには範囲が狭すぎる。 3 12 17
ベンダーの真摯さ
| 評価基準 | 点数 |
|---|---|
| 対外発信の技術的な真摯さ | 3/10 |
| 技術ロードマップの一貫性 | 4/10 |
| 概念の明晰さ | 4/10 |
| 経済的な結果への責任 | 3/10 |
| エージェント型ソフトウェア時代における競争力の持続性 | 4/10 |
平均：3.6/10。
対外発信の技術的な真摯さ — 3/10。 詳細な技術説明は、重要な限界を消し去る断定的な安全性・性能の主張によって弱められている。 3 17
技術ロードマップの一貫性 — 4/10。 Hypertrustは発表だけに終わらない継続的な製品開発を示す。文書化された機構から、量子最適化を含む普遍的な性能主張への飛躍は、依然として裏付けが弱い。 14 16 8
概念の明晰さ — 4/10。 製品は製造と不確実性の難しい問題を認識する。一方、設定可能な手法と一貫した計画を、それらの問題への経済的に健全な解決と安易に同一視する。 4 8
経済的な結果への責任 — 3/10。 顧客証拠は有用な活動を説明するが、ソフトウェアとサービスを合わせた契約を持続的な純リターンや不適切な意思決定モデルの修正に結び付ける公開機構はない。 11 12
エージェント型ソフトウェア時代における競争力の持続性 — 4/10。 業界固有の制約、連携、動作するアプリケーションには価値がある。その価値を保つには、大規模なスイートの操作を計画担当者に支援する以上の、安価な改善工程が必要である。 8 11 18
出典
出典は2026年11月4日に確認した。アーカイブページは、ドメインがAccentureへ転送される以前のAvatarの提供内容を記録する。現在の製品版や契約条件を確定するものではない。
Elixumホームページ、2026年4月20日の保存版。製品構成、拡張モデル、費用上の位置付け。現行ドメインは確認時にAccentureへ転送された。
Accentureの発表、2024年10月28日。
技術ページ、2026年4月20日の保存版。中心モデル、エンジン、ソルバーの主張、拡張環境。
供給ページ、2026年2月11日の保存版。計画目的と協業。
需要ページ、2026年2月11日の保存版。予測と担当者の修正の評価。
在庫ページ、2026年4月20日の保存版。分類、DDMRP、パラメーター保守。
リスクページ、2026年4月20日の保存版。ネットワークモデル、混乱シナリオ、緩和策。
Elixumの生産文書。検索登録された公開版。製造制約、確率的スケジューリング、最適化エンジンの位置付け。
[9] Hypertrustアプリケーションプラットフォーム
プラットフォームページ、2026年4月20日の保存版。配置の選択肢、拡張、安全性、連携。
企業ネットワークページ、2026年1月20日の保存版。連邦型データと参加者の共有方針。
Elixumのサービス文書。検索登録された公開版。導入、改善、展開、研修。
Elixumの顧客事例、2025年2月25日。導入を説明する検索登録された公開版。
Elixumの発表、2023年11月24日。10月5日の移行を報告。検索登録された公開版。
PRWeb経由のCamelotの発表、2018年4月23日。
[15] Hypertrust Identity Managementの発売
Presseportal経由のCamelotの発表、2018年10月2日。明示されたID技術と連携。
[16] オフチェーンのスマートコントラクト向けブロックチェーン
SAPが公開するCamelotとDellの発表資料、2018年11月。非公開データと合意した計算の設計。
Dell Technologiesのホワイトペーパー、保存コピー、2020年4月。参照アーキテクチャ、構成部品、安全性の主張、概念実証の成果。
[18] AvatarとHypertrustのフロントエンド開発
開発者による公開職務説明。製品固有の担当業務と構成要素。
[19] Hypertrust X-Chainのバックエンド開発
開発者による公開職務説明。製品固有のサービス、データベース作業、配信ツール。