DFT review
This kit organizes Digital Fabrica Theory materials for structured inspection. It is a review-preparation artifact. It does not imply external approval, peer review, certification, institutional endorsement, or scientific acceptance.
Reviewer export packet
These packets organize DFT materials for scientific, technical, institutional, implementation, and publication review. They are prepared for inspection and do not imply approval, peer review, certification, or external validation.
general-expert
Provide a structured inspection path across DFT theory, architecture, applications, implementations, evidence maturity, and review gaps.
scientific-reviewer
Help scientific reviewers inspect definitions, primitives, formalization targets, assumptions, and proof obligations.
technical-reviewer
Help technical reviewers inspect DFDF, FNS, IDFF, SIDS, interoperability boundaries, and implementation-readiness gaps.
implementation-reviewer
Help implementation reviewers inspect Stitchia, GFE, and other implementation candidates without treating them as proof of DFT.
publication-reviewer
Help publication reviewers inspect DOI/archive state, citation health, publication status, provenance boundaries, and missing records.
Maturity ladder
A record can move upward only when evidence improves. This protects the public DFT corpus from implying more than the record supports.
Score 0
The entity, concept, or route is named, but has not yet been supported by current source evidence.
Score 1
The claim is supported by an internal or public source record and has clear validation boundaries.
Score 2
The claim is supported by reachable public route evidence, title, metadata, or page text.
Score 3
The claim is connected to a concrete implementation candidate with an evidence table and missing-evidence boundary.
Score 4
The claim is supported by published operational evidence with scope, date, responsible entity, and limitations.
Score 5
The claim is supported by independent review, certification, peer review, audit, or formal external evaluation within a clearly stated scope.
Public reviewer checklist
This checklist gives reviewers a structured path through theory, architecture, institutional boundaries, implementation evidence, and publication provenance.
Core terms have definitions, related terms, and formalization boundaries.
Definitions remain metaphorical without primitives, assumptions, or review path.
Each layer has role, boundary, and implementation evidence requirements.
Architecture layers collapse into vague branding or unsupported protocol claims.
Public pages avoid implied accreditation or external validation.
Publication or institutional language implies approval without evidence.
Implementation pages include evidence boundaries and do not validate full DFT.
Implementation existence is treated as proof or certification of the theory.
Publication records distinguish provenance, DOI/archive, and review status.
DOI or archive records imply peer review or scientific acceptance.
Evidence maturity
Evidence maturity scores what each DFT record may safely claim today and what evidence is needed before stronger claims can be made.
The entity, concept, or route is named, but has not yet been supported by current source evidence.
The claim is supported by an internal or public source record and has clear validation boundaries.
The claim is supported by reachable public route evidence, title, metadata, or page text.
The claim is connected to a concrete implementation candidate with an evidence table and missing-evidence boundary.
The claim is supported by published operational evidence with scope, date, responsible entity, and limitations.
The claim is supported by independent review, certification, peer review, audit, or formal external evaluation within a clearly stated scope.
| Record | Current level | Reason | Next evidence needed |
|---|---|---|---|
| Digital Fabrica Theory | M1-source-bounded | DFT has public theory, ontology, architecture, and source-boundary routes, but not external validation. |
|
| DFT Architecture Stack | M1-source-bounded | DFDF/FNS/IDFF/SIDS are now publicly modeled and diagrammed, but not formal specifications or certified standards. |
|
| YellowChain | M1-source-bounded | YellowChain is classified as a strategic governance/identity fabric, but current public route evidence remains incomplete. |
|
| New Millennium Frontier | M2-live-site-supported | NMF has live-site support and is framed as a verifiable-science coordination layer, while validation boundaries remain explicit. |
|
| CitizenSolar | M2-live-site-supported | CitizenSolar has live public positioning as an energy infrastructure domain, but operational telemetry and deployment evidence remain pending. |
|
| CySys | M1-source-bounded | CySys is classified as enterprise cybernetic infrastructure/advisory arm, but live service/case evidence needs capture. |
|
| Stitchia | M3-implementation-candidate | Stitchia is classified as a concrete implementation candidate, with evidence boundaries and missing technical/compliance review items. |
|
| Global Freight Exchange | M3-implementation-candidate | GFE is classified as a concrete logistics implementation candidate, with explicit marketplace/settlement overclaim boundaries. |
|
Cross-domain evidence ledger
This ledger separates theory sources, architecture models, critical applications, implementations, publication records, domain evidence, and review gaps. Evidence supports scoped claims only; it does not validate the entire theory by itself.
| Record | Class | Status | Supports | Missing | Boundary |
|---|---|---|---|---|---|
| Digital Fabrica Theory | theory-source | source-bounded |
|
| DFT is presented as a source-bounded research and architecture framework, not an externally validated universal theory. |
| DFT Architecture Stack | architecture-model | source-bounded |
|
| The stack is an architecture model and formalization target, not a certified standard. |
| YellowChainyellowchain.org | critical-application | evidence-needed |
|
| YellowChain is a strategic critical application. Operational DID, ledger, and governance claims require separate evidence. |
| New Millennium Frontiernewmillenniumfrontier.org | critical-application | live-site-supported |
|
| NMF is a coordination layer. It does not replace universities, journals, or external peer review. |
| CitizenSolarcitizen.solar | critical-application | live-site-supported |
|
| CitizenSolar is an energy infrastructure application domain. Operational and performance claims require published evidence. |
| CySyscy-systems.com | critical-application | evidence-needed |
|
| CySys is the enterprise infrastructure and advisory arm. Deployment, adoption, and audited infrastructure claims require source evidence. |
| Stitchiastitchia.xyz | implementation | implementation-candidate |
|
| Stitchia is an implementation candidate, not certified compliance infrastructure unless separately documented. |
| Global Freight Exchangefreight-exchange.org | implementation | implementation-candidate |
|
| GFE is a logistics implementation candidate. It must not imply regulated exchange status, market scale, or live settlement without evidence. |
Review gaps
Review gaps identify what remains incomplete before stronger claims can be made. They are part of the evidence discipline of DFT.
DFT primitives require formal specification beyond public definitions.
Why it matters: Formal definitions are needed before theorem claims, conformance tests, or proof obligations can be evaluated.
Governance, DID, and resource-ledger evidence need current public documentation.
Why it matters: YellowChain is a strategic critical application but cannot be treated as operational implementation evidence without updated records.
Enterprise service model and deployment evidence need clearer separation.
Why it matters: CySys must distinguish advisory positioning, implementation candidates, and deployed evidence.
Stitchia and GFE need technical architecture packets.
Why it matters: Implementation candidates become stronger evidence only when architecture, status, and review boundaries are explicit.
Core whitepapers need verified DOI/archive records.
Why it matters: DOI and archive records improve provenance and preservation while preserving validation boundaries.