Open Prompt — a knowledge-sharing paradigm for the LLM era

This is the log I have been pointing toward in every previous one.

The FPGA Spectrum Engine is being released under a knowledge-sharing scheme I call Open Prompt. This log is the formal declaration: what Open Prompt is, what it is not, why it exists, what it shares, and how others can adopt it for their own projects.

It is also, by necessity, a log about how engineering knowledge propagates in a world where capable engineers and capable language models collaborate as a matter of course. That world is already here. The question is whether our knowledge-sharing conventions have caught up with it.

Why a new paradigm is needed

For four decades, open source has been the dominant model for sharing engineering knowledge. It works by distributing source code under a license that permits — and structures — its reuse, modification, and redistribution. The code is the artifact. The license is the social contract. Forking, attribution, and copyleft are the operational mechanisms.

Open source is one of the most successful intellectual movements in modern history. Nothing here is meant to diminish it.

But open source was designed in a world where the source code was the bottleneck. Producing source code took human time measured in days, weeks, and years. Sharing it meant sharing the scarcest resource. The license structure exists because the artifact was hard-won.

That world is changing. In a world where a capable engineer with a capable language model can regenerate functional source code from an architectural description in hours, the source code is no longer the bottleneck. What was scarce becomes abundant. What was abundant — clarity of architecture, precision of reasoning, transparency of design intent — becomes scarce.

Open source distributes the abundant resource and licenses around its scarcity. We need a paradigm that distributes the scarce resource and lets the abundant one regenerate freely.

That paradigm is what I am calling Open Prompt.

What Open Prompt is

Open Prompt distributes engineering knowledge in three layers:

Layer 1 — Architectural Specification

The mathematics, the constraints, the structural decisions, the invariants. Written for a competent engineer to read directly. Sufficient — in combination with current language model capabilities — for that engineer to regenerate a working implementation.

For the FPGA Spectrum Engine, Layer 1 includes:

• The 11th-order Maclaurin truncation and its error bound
• The 3-layer hardware architecture (PC / ARM HPS / FPGA)
• The bin-direct addressing principle
• The iDFT/SDFT duality
• The synthesis paradigm unification (FM, additive, fractal, polygonal as bin patterns)

This layer is the commons. It is in the public domain. Anyone may read it, redistribute it, build on it, write derivative explanations of it, teach it.

Layer 2 — Reasoning Trace

The actual design conversations and decision logs that led from constraints to implementation. This layer is what is genuinely new in the LLM era.

Engineering decisions are rarely fully reconstructible from the specification alone. "Why this and not that" lives in the process of arriving at the specification. Historically, that process was lost — preserved only in scattered notebooks, mailing list threads, and the memories of the engineers involved.

In the LLM era, however, a substantial portion of engineering reasoning takes place as dialogue with language models. Those dialogues are literally exportable as text. They can be saved, versioned, shared, and replayed. A reader who replays such a dialogue with their own language model collaborator does not just read the reasoning — they can resume it.

For this project, Layer 2 includes:

• Architectural design dialogues (with myself, with collaborators, with LLM partners)
• Recorded decision rationale at branching points
• Build Log conversations that produced the published Build Logs themselves

These traces are made available as paired Markdown (for human reading) and JSON (for direct ingestion by language models). A future engineer regenerating their own implementation can begin not from a blank page but from the pre-loaded context of the original reasoning, accelerated to the present.

Layer 3 — Sample Implementations

The actual source code, schematics, MAX patches, scripts, and similar concrete artifacts that I personally produce in the course of building the engine.

This layer is illustrative, not normative. It is one possible implementation, made by one engineer (me), in one set of constraints, on one set of devices, at one moment in time. Other engineers regenerating from Layers 1 and 2 will produce different implementations. Their implementations are not derivatives of mine. They are independent answers to the same question.

Sample implementations are released under a permissive open-source license (specifics in the project repository). They serve as reference points for engineers who want to compare their own regenerated work against an existing example, and for educators who want concrete material to teach with.

What is shared, what is not, and what is everyone's

The three-layer structure produces a clean ownership distribution:

Layer	Status	Owner
Layer 1: Architectural Specification	Commons (public domain)	No one / everyone
Layer 2: Reasoning Trace	Commons (public domain)	No one / everyone
Layer 3: Sample Implementations (mine)	Open-source license (permissive)	Me, as author
Layer 3: Implementations regenerated by others	At each author's discretion	The regenerator

Critically, an implementation regenerated from Layers 1 and 2 by another engineer is not a derivative work of my Layer 3 sample. It is an independent answer to the architectural specification, produced by a different engineer with a different process. The regenerator owns it outright. They may license it however they choose — open source, commercial, kept private. That choice is theirs.

This is the structural difference from open source. Under traditional open source, an implementation derived from my code inherits the license obligations of my code. Under Open Prompt, an implementation regenerated from my architecture inherits nothing from my code, because it does not descend from my code. It descends from the specification, which is the commons.

Why this works in 2026 specifically

Open Prompt would not have been a viable paradigm five years ago. The mechanism that makes it work — that an architectural specification, combined with a reasoning trace, is sufficient input for a competent engineer plus a capable language model to regenerate working source code — depends on the language models being capable enough.

That threshold has been crossed. As of 2026, a working engineer collaborating with a frontier-class language model can routinely move from a precise architectural specification to functional source code in time scales that were previously occupied by source-code authorship itself.

This shifts where the slow, careful work happens. The slow, careful work is now in the specification and the reasoning, not in the typing of code. The typing of code is increasingly the regenerable, abundant phase. The thinking that produces a clean specification — the part that is genuinely hard, that takes decades of experience, that cannot be automated — is the part worth distributing.

Open Prompt makes that distribution explicit.

A note on prompt engineering

When language models first became broadly accessible, "prompt engineering" emerged as a discipline focused on crafting one-shot inputs that would elicit desired outputs. Benchmarks and tutorials accumulated around the question of what to put in a single prompt.

That phase is largely over. The current understanding among practitioners is that prompting is a multi-turn dialogue, not a one-shot incantation. The skill that matters is sustaining a productive collaborative thinking process across many turns — clarifying, course-correcting, reformulating, resuming. A single-shot prompter is increasingly recognized as an early-stage user.

This shift is what makes Layer 2 (Reasoning Trace) sensible to share. A one-shot prompt is not interesting to share — it is just a sentence. A multi-turn design dialogue, however, is a record of how a complex engineering problem was thought through. It is the modern equivalent of a laboratory notebook. Sharing it is sharing the most valuable kind of engineering knowledge there is.

The repository structure

To make Open Prompt a concrete and reproducible distribution format, I propose the following repository structure as a template:

ProjectName_OpenPrompt/
├── README.md                          # Project overview and navigation
├── LICENSE_OpenPrompt.md              # The Open Prompt declaration for this project
│
├── 01_Architecture/                   # Layer 1 — Specification (commons)
│   ├── overview.md
│   ├── core_mathematics.md
│   ├── system_architecture.md
│   ├── design_constraints.md
│   └── ... (project-specific)
│
├── 02_Reasoning_Traces/               # Layer 2 — Dialogues (commons)
│   ├── README.md                      # How to read, how to resume
│   ├── 2026-04-design-dialogue.md     # Human-readable conversation log
│   ├── 2026-04-design-dialogue.json   # LLM-ingestible conversation log
│   └── ... (chronological, append-only)
│
├── 03_Sample_Implementations/         # Layer 3 — Reference code (author-licensed)
│   ├── README.md                      # What is here, what is not, what license
│   ├── horner_pipeline_verilog/
│   ├── max_patches/
│   ├── bin_pattern_generators/
│   └── ... (project-specific)
│
└── CONTRIBUTING.md                    # How others can contribute (Layer 1/2 only)

A repository following this layout is, by structure alone, an Open Prompt distribution. The structure itself becomes the social contract — analogous to how a LICENSE file at the root of a repository communicates open-source intent.

The FPGA Spectrum Engine repository will be published in this exact structure, at a URL announced in a follow-up Build Log.

What Open Prompt is not

Open Prompt is not anti-open-source. It includes open source. Layer 3 (sample implementations) is released under a permissive open-source license. Anyone who wants to fork the sample, modify it, and redistribute it under standard open-source rules may do so. What Open Prompt adds is a parallel path — for engineers who want to regenerate from the architecture itself rather than fork from the sample. Both paths are legitimate.

Open Prompt is not a license. It is a structural distribution scheme. Layers 1 and 2 are placed in the public domain explicitly. Layer 3 carries whatever license the original author chooses for it. The novelty is in the layering, not in any new legal instrument.

Open Prompt is not LLM-dependent. A competent engineer, working without any language model, can still read Layer 1 and Layer 2 and regenerate an implementation from them. The LLM accelerates the regeneration; it does not enable it. Open Prompt would still be a coherent paradigm in a world without language models — it would just be slower.

Open Prompt is not a claim that source code is unimportant. Source code remains the executable artifact. Open Prompt simply observes that, in 2026 and onward, source code is no longer the bottleneck in knowledge transfer. The bottleneck has moved upstream, and Open Prompt is an attempt to distribute knowledge at the new bottleneck.

Open Prompt is not yet standardized. This declaration is one project's adoption of a paradigm I believe should exist. Whether that paradigm becomes broadly adopted — whether the three-layer structure crystallizes into convention, whether the repository template becomes a recognizable signal, whether other projects adopt it — depends on the community.

This declaration is an invitation, not a fait accompli.

Adoption — for projects that want to follow

Other engineers who wish to release projects as Open Prompt are welcome to use this scheme. The adoption procedure is simple:

1. Structure the repository in the three-layer template above (or a clearly-derived variant).
2. Place Layer 1 and Layer 2 in the public domain, explicitly. A standard CC0 dedication works for both layers.
3. License Layer 3 as you choose. Permissive open-source licenses are recommended but not required.
4. Include an Open Prompt declaration in the repository — referencing this Build Log, or your own equivalent declaration, is sufficient.
5. Maintain the reasoning trace as you go. Layer 2 is not a one-time export at project end; it accumulates throughout the project's life. New design conversations are appended chronologically.

That is the entire protocol. There is no central registry, no certifying body, no required attribution beyond what each contributing engineer chooses for their own Layer 3.

What I am asking of readers

If you are an FPGA engineer and you regenerate this architecture into your own implementation: publish your reasoning trace. Even if you keep your final source private, the trace of how you got there belongs to the commons. Your dialogue with your language model — about why you chose Horner over accumulate-and-multiply, about what polynomial degree fit your constraints, about how you partitioned your error budget — is exactly the material that future engineers will need.

If you are a researcher or educator: the architecture and reasoning traces are yours to teach with, write about, build on, criticize, refine. No permission needed. Attribution welcome but not required.

If you are an engineer working on something completely different — robotics, networking, mechanical design, anything: consider whether your project would benefit from this structure. The three-layer division is not specific to FPGA work or to digital signal processing. It is a general scheme for knowledge sharing in a world where regeneration from specification is cheaper than transfer of source code.

Closing — and a return to the project

The FPGA Spectrum Engine is a real engineering project with concrete goals: 10,240 oscillators, 1-sample latency, 0.001 Hz resolution, real-time spectral synthesis on a Cyclone V SoC. The Build Logs in this series document its design, its history, and its current status as a working compute substrate awaiting the new abstraction layer.

Open Prompt is the form in which this project is released. It exists because I want this engineering knowledge to outlive the source code it temporarily inhabits. Code is ephemeral; the knowledge architecture is the commons.

Forty years of FPGA practice taught me that the lasting contribution is never the bitstream. It is always the way of seeing the problem that produced the bitstream. Open Prompt is my attempt to share the way of seeing.

What the readers do with it is no longer mine to determine. That, finally, is the point.

Coming next

• Build Log #3 — Synthesis paradigm lineage: from Chowning's 1973 FM equation to the spectral fractal direction, and where this engine sits on that timeline. (Now to be read in the Open Prompt frame: a historical Layer-1-style document.)

Project repository (Open Prompt structure): announced in a follow-up Build Log Companion interactive page: dsohnaka/FPGA_Spectrum_Engine_OpenPrompt

---

▼ Build Log 本文（日本語版・併記用）

オープンプロンプト — LLM 時代の知識共有パラダイム

これは、これまでのすべての Build Log が指し示してきたログである。

FPGA Spectrum Engine は、私がオープンプロンプトと呼ぶ知識共有方式のもとに公開される。本ログはその正式な宣言である：オープンプロンプトとは何か、何でないか、なぜ存在するのか、何を共有するのか、そして他者が自身のプロジェクトのためにどう採用できるか。

本ログは同時に、必然的に、有能なエンジニアと有能な言語モデルが当然のように協働する世界における工学知識の伝播に関するログでもある。その世界はすでに到来している。問題は、私たちの知識共有の慣習がそれに追いついているかどうかである。

なぜ新しいパラダイムが必要か

40年にわたって、オープンソースは工学知識を共有する支配的モデルだった。それはソースコードを、再利用・改変・再配布を許容し構造化するライセンスのもとに配布することで機能する。コードが成果物。ライセンスが社会的契約。フォーク、帰属表示、コピーレフトが運用機構。

オープンソースは現代史における最も成功した知的運動の一つである。ここで述べることは何一つそれを貶めるものではない。

しかし、オープンソースはソースコードがボトルネックだった世界のために設計された。ソースコードの生成には日・週・年単位の人間時間がかかった。それを共有することは、最も希少な資源を共有することだった。ライセンス構造が存在するのは、成果物が苦労して獲得されるものだったからである。

その世界が変わりつつある。有能なエンジニアと有能な言語モデルが、アーキテクチャ記述から動作するソースコードを数時間で再生成できる世界では、もはやソースコードはボトルネックではない。希少だったものが豊富になる。豊富だったもの——アーキテクチャの明晰さ、推論の精密さ、設計意図の透明性——が希少になる。

オープンソースは豊富な資源を配布し、その希少性の周りでライセンスを構築する。私たちは希少な資源を配布し、豊富な資源を自由に再生成させるパラダイムを必要としている。

そのパラダイムが、私がオープンプロンプトと呼ぶものである。

オープンプロンプトとは何か

オープンプロンプトは工学知識を3つの層で配布する：

第1層 — アーキテクチャ仕様

数学、制約、構造的決定、不変量。有能なエンジニアが直接読めるように書かれる。現代の言語モデル能力との組み合わせにより、そのエンジニアが動作する実装を再生成するに十分なもの。

FPGA Spectrum Engine の第1層には以下が含まれる：

• 11次マクローリン打ち切りとその誤差上界
• 3層ハードウェアアーキテクチャ（PC / ARM HPS / FPGA）
• ビン直接アドレス原理
• iDFT/SDFT 双対性
• 合成パラダイム統一（FM、加算、フラクタル、ポリゴナルがビンパターンとして）

この層は共有財産である。パブリックドメインに置かれる。誰でも読み、再配布し、その上に構築し、派生説明を書き、教えてよい。

第2層 — 推論軌跡

制約から実装へと導いた実際の設計対話と決定記録。この層こそが LLM 時代において真に新しいものである。

工学的決定は、仕様だけからは完全には再構成できないことが多い。「なぜこれであってあれでないか」は仕様に到達する過程に宿る。歴史的にはその過程は失われた——散在するノート、メーリングリストのスレッド、関わったエンジニアの記憶のなかにのみ保存された。

しかし LLM 時代において、工学的推論のかなりの部分が言語モデルとの対話として行われる。それらの対話は文字どおり、テキストとしてエクスポート可能である。保存し、版管理し、共有し、再生できる。そのような対話を自身の言語モデル協働者と再生する読者は、推論を読むだけではない——それを再開できる。

本プロジェクトでの第2層には以下が含まれる：

• アーキテクチャ設計対話（自己との、協働者との、LLM パートナーとの）
• 分岐点における決定根拠の記録
• 公開された Build Log そのものを生成した対話

これらの軌跡は、人間が読むための Markdown と、言語モデルが直接取り込むための JSON のペアとして提供される。自身の実装を再生成する未来のエンジニアは、白紙からではなく、元の推論の事前ロード済みコンテクストから、現在まで加速された地点から始めることができる。

第3層 — サンプル実装

エンジン構築の過程で私個人が生成する、実際のソースコード、回路図、MAX パッチ、スクリプト、その他の具体的成果物。

この層は例示的であり規範的ではない。それは一人のエンジニア（私）が、ある制約集合のもとで、ある一連のデバイス上で、ある一時点で行った、一つの可能な実装である。第1層と第2層から再生成する他のエンジニアは異なる実装を生み出す。彼らの実装は私の派生物ではない。同じ問いに対する独立した答えである。

サンプル実装は寛容なオープンソースライセンス（詳細はプロジェクトリポジトリで規定）のもとに公開される。自身の再生成成果物を既存の例と比較したいエンジニア、教えるための具体的素材を欲する教育者にとってのリファレンスポイントとして機能する。

何が共有され、何が共有されず、何が万人のものか

3層構造は綺麗な所有権分布を生み出す：

層	状態	所有者
第1層：アーキテクチャ仕様	共有財産（パブリックドメイン）	誰でもなく / 全員
第2層：推論軌跡	共有財産（パブリックドメイン）	誰でもなく / 全員
第3層：サンプル実装（私のもの）	オープンソースライセンス（寛容）	私（著者として）
第3層：他者により再生成された実装	各著者の判断	再生成者

重要な点として、他のエンジニアが第1層と第2層から再生成した実装は、私の第3層サンプルの派生物ではない。それは異なるエンジニアが異なる過程で生み出した、アーキテクチャ仕様への独立した答えである。再生成者がそれを完全に所有する。彼らはそれを好きなようにライセンスできる——オープンソースで、商用で、非公開で。その選択は彼らのものである。

これがオープンソースとの構造的差異である。伝統的オープンソースのもとでは、私のコードから派生した実装は私のコードのライセンス義務を継承する。オープンプロンプトのもとでは、私のアーキテクチャから再生成された実装は私のコードから何も継承しない——私のコードから降りてきていないからである。それは仕様から降りてきており、仕様は共有財産である。

なぜこれが特に2026年に機能するのか

オープンプロンプトは5年前には実現可能なパラダイムではなかった。それを機能させる機構——アーキテクチャ仕様と推論軌跡の組み合わせが、有能なエンジニアと有能な言語モデルが動作するソースコードを再生成する入力として十分であること——は、言語モデルが十分に有能であることに依存する。

その閾値は越えられた。2026年現在、フロンティア級言語モデルと協働する実働エンジニアは、精密なアーキテクチャ仕様から動作するソースコードへ、かつてはソースコード執筆そのものに費やされた時間スケールで日常的に移動できる。

これは慎重な作業がどこで行われるかを変える。慎重な作業はもはやコードのタイピングではなく、仕様と推論にある。コードのタイピングは、ますます再生成可能で豊富な段階となる。清潔な仕様を生み出す思考——本当に難しい部分、何十年もの経験を必要とし、自動化できない部分——こそが、配布する価値のある部分である。

オープンプロンプトはその配布を明示化する。

プロンプトエンジニアリングについての注

言語モデルが広く利用可能になり始めたとき、「プロンプトエンジニアリング」は望ましい出力を引き出すワンショット入力を作る規律として現れた。ベンチマークやチュートリアルが、単一プロンプトに何を入れるかという問いの周りに蓄積された。

その段階はおおむね終わった。実践者の現在の理解は、プロンプティングはマルチターンの対話であり、ワンショットの呪文ではないということである。重要な技能は、多くのターンにわたって生産的な協働思考プロセスを維持すること——明確化、軌道修正、再定式化、再開——である。ワンショットプロンプターはますます初期段階のユーザーとして認識される。

この変化こそが、第2層（推論軌跡）を共有することを意義あるものにする。ワンショットプロンプトは共有して興味深いものではない——ただの一文である。マルチターンの設計対話は、しかし、複雑な工学問題がどう考え抜かれたかの記録である。それは現代における実験ノートの等価物である。それを共有することは、存在する最も価値ある種類の工学的知識を共有することである。

リポジトリ構造

オープンプロンプトを具体的で再現可能な配布形式とするため、以下のリポジトリ構造をテンプレートとして提案する：

ProjectName_OpenPrompt/
├── README.md                          # プロジェクト概要とナビゲーション
├── LICENSE_OpenPrompt.md              # 本プロジェクトのオープンプロンプト宣言
│
├── 01_Architecture/                   # 第1層 — 仕様（共有財産）
│   ├── overview.md
│   ├── core_mathematics.md
│   ├── system_architecture.md
│   ├── design_constraints.md
│   └── ... （プロジェクト固有）
│
├── 02_Reasoning_Traces/               # 第2層 — 対話（共有財産）
│   ├── README.md                      # 読み方、再開の仕方
│   ├── 2026-04-design-dialogue.md     # 人間可読の対話ログ
│   ├── 2026-04-design-dialogue.json   # LLM 取り込み可能な対話ログ
│   └── ... （時系列、追記のみ）
│
├── 03_Sample_Implementations/         # 第3層 — リファレンス実装（著者ライセンス）
│   ├── README.md                      # 何があるか、何がないか、ライセンス
│   ├── horner_pipeline_verilog/
│   ├── max_patches/
│   ├── bin_pattern_generators/
│   └── ... （プロジェクト固有）
│
└── CONTRIBUTING.md                    # 他者がどう貢献できるか（第1/2層のみ）

このレイアウトに従うリポジトリは、構造のみによってオープンプロンプト配布である。構造そのものが社会的契約となる——リポジトリのルートにある LICENSE ファイルがオープンソース意図を伝えるのと同様に。

FPGA Spectrum Engine リポジトリは、まさにこの構造で公開される——URL は後続の Build Log で告知する。

オープンプロンプトは何ではないか

オープンプロンプトはオープンソース反対ではない。それはオープンソースを包含する。第3層（サンプル実装）は寛容なオープンソースライセンスのもとに公開される。サンプルをフォーク、改変、標準的なオープンソース規則のもとで再配布したい者は誰でもそうできる。オープンプロンプトが追加するのは並行する経路——サンプルをフォークするのではなくアーキテクチャそのものから再生成したいエンジニアのため。両経路とも正当である。

オープンプロンプトはライセンスではない。それは構造的配布スキームである。第1層と第2層は明示的にパブリックドメインに置かれる。第3層は元の著者が選んだライセンスを伴う。新規性は層構造にあり、新しい法的道具にはない。

オープンプロンプトは LLM 依存ではない。言語モデルなしで作業する有能なエンジニアも、第1層と第2層を読んで実装を再生成できる。LLM は再生成を加速する；可能にするのではない。言語モデルなしの世界においてもオープンプロンプトは首尾一貫したパラダイムであっただろう——ただ遅かっただけで。

オープンプロンプトはソースコードが重要でないとの主張ではない。ソースコードは依然として実行可能成果物のままである。オープンプロンプトは単に、2026 年以降においてはソースコードがもはや知識転送におけるボトルネックではない、と観察するだけである。ボトルネックは上流に移動した。オープンプロンプトはその新しいボトルネックにおいて知識を配布する試みである。

オープンプロンプトはまだ標準化されていない。本宣言は、私が存在すべきだと信じるパラダイムへの、一プロジェクトによる採用である。そのパラダイムが広く採用されるか——3層構造が慣行に結晶化するか、リポジトリテンプレートが認識可能なシグナルとなるか、他のプロジェクトが採用するか——はコミュニティ次第である。

本宣言は招待状であり、既成事実ではない。

採用方法 — 後続を望むプロジェクトへ

オープンプロンプトとして自身のプロジェクトを公開したい他のエンジニアは、本スキームを利用してよい。採用手順は単純である：

1. リポジトリを上記の3層テンプレート（または明確に派生した変種）に従って構造化する
2. 第1層と第2層を明示的にパブリックドメインに置く。両層に対し標準的な CC0 dedication で十分
3. 第3層を任意のライセンスにする。寛容なオープンソースライセンスが推奨されるが必須ではない
4. オープンプロンプト宣言をリポジトリに含める——本 Build Log への参照、または自身の同等宣言で十分
5. 進捗とともに推論軌跡を維持する。第2層はプロジェクト終了時の一回限りのエクスポートではない；プロジェクトの全期間にわたって蓄積する。新しい設計対話は時系列で追加される

これがプロトコル全体である。中央レジストリも、認証団体も、各貢献エンジニアが自身の第3層に対して選ぶもの以外の必須帰属表示もない。

読者への問いかけ

あなたが FPGA エンジニアで、本アーキテクチャを自身の実装に再生成するなら：推論軌跡を公開してほしい。最終的なソースを非公開のまま保つにしても、そこに到達した道筋の軌跡は共有財産に属する。あなたの言語モデルとの対話——なぜ Horner を選び累積積算を選ばなかったか、どの多項式次数があなたの制約に適合したか、誤差予算をどう分配したか——こそが、未来のエンジニアが必要とするまさにその素材である。

あなたが研究者または教育者なら：アーキテクチャと推論軌跡はあなたが教える、書く、その上に構築する、批判する、洗練するためのものである。許可は不要。帰属表示は歓迎するが必須ではない。

あなたがまったく異なるもの——ロボティクス、ネットワーキング、機械設計、その他何でも——に取り組むエンジニアなら：自身のプロジェクトがこの構造の恩恵を受けるかどうか考えてほしい。3層分割は FPGA 仕事やデジタル信号処理に特有のものではない。それは仕様からの再生成がソースコードの転送より安価な世界における、知識共有の一般的スキームである。

プロジェクトリポジトリ：dsohnaka/FPGA_Spectrum_Engine_OpenPrompt