> Full-text translation from Chinese. The original remains authoritative for its research claims; this translation is not independent mathematical verification. # DMSD Generalized Formal Core v1 ## Multiscale Serializable Mathematical Domain — Property-Independent Formalization **Version:** v1.0 **Date:** 2026-09-30 **Nature:** Generalized Formal Core **Positioning:** Abstract DMSD from a decimal/prime-specific prototype into a property-independent runtime framework --- # 1. Central Purpose DMSD's core is no longer defined as: > Viewing primes through a decimal pyramid. Instead, it is defined as: > **For mathematical domains that may be theoretically unbounded but must be operated on finitely in practice, establish a unified runtime for serializable scales, local resolution, knowledge states, property summaries, source depth and budget policy.** Thus: \[ \boxed{ \text{DMSD Core} \neq \text{Prime Model}. } \] Primes are merely a stress-test plugin. --- # 2. Core Object DMSD v1 is provisionally defined as: \[ \boxed{ \mathfrak D = ( \mathcal G, \mathcal B, \mathcal R, \mathcal L, \mathcal K, \mathcal A, \mathcal M, \mathcal F, \Pi, \mathcal H ) } \] where: - \(\mathcal G\): Scale Grammar; - \(\mathcal B\): Block Space; - \(\mathcal R\): Refinement Operators; - \(\mathcal L\): Property Layers; - \(\mathcal K\): Knowledge States; - \(\mathcal A\): Summary Algebras; - \(\mathcal M\): Baseline / Residual Models; - \(\mathcal F\): Source-Efficiency Frontiers; - \(\Pi\): Budgeted Source Policies; - \(\mathcal H\): Provenance / History. --- # 3. Scale Grammar Define: \[ \mathcal G=(I,\gamma,\preceq), \] where: - \(I\): scale index set; - \(\gamma(k)\): domain block corresponding to level \(k\); - \(\preceq\): scale ordering. Decimal is merely: \[ \gamma_{10}(k) = [10^k,10^{k+1}). \] Binary, octal, hex and adaptive scales are simply different instances of: \[ \mathcal G. \] Thus: \[ \boxed{ \text{Scale Grammar} \neq \text{Mathematical Ontology}. } \] --- # 4. Block A block: \[ \boxed{ B = ( g, k, [a,b), \rho, \eta, \pi_B ) } \] where: - \(g\): scale grammar; - \(k\): scale index; - \([a,b)\): actual domain region; - \(\rho\): resolution depth; - \(\eta\): source depth; - \(\pi_B\): refinement path. Thus: \[ \boxed{ \rho \neq \eta. } \] Spatial / resolution refinement and source / epistemic refinement are independent axes. --- # 5. Refinement Operator For the block: \[ B, \] refinement: \[ \mathcal R(B) = (B_1,\ldots,B_m) \] must satisfy: \[ B = \bigsqcup_{i=1}^{m}B_i. \] That is: ### Coverage \[ \bigcup_i B_i=B. \] ### Disjointness \[ B_i\cap B_j=\varnothing \qquad i\neq j. \] ### Order Preservation If the domain is ordered: \[ b_i=a_{i+1}. \] --- # 6. Property Layer An arbitrary property / mathematical task \(Q\) is registered as a plugin: \[ \boxed{ \mathfrak P_Q = ( Q, \Sigma_Q, \sigma_Q, \oplus_Q, \Gamma_Q ) } \] where: - \(Q\): property / target; - \(\Sigma_Q\): summary state space; - \(\sigma_Q(B)\): block summarizer; - \(\oplus_Q\): summary merge algebra; - \(\Gamma_Q\): certificate / admission rules. --- # 7. Summary Algebra If: \[ B=\bigsqcup_iB_i \] and all child summaries have sufficient exactness, then require: \[ \boxed{ \sigma_Q(B) = \bigoplus_i\sigma_Q(B_i). } \] This is one of DMSD's most central algebraic invariants. Examples: ### Parity \[ \Sigma_Q=(O,E) \] \[ (O,E) = \sum_i(O_i,E_i). \] ### Residue \[ \Sigma_Q= (C_0,\ldots,C_{m-1}). \] ### Square \[ \Sigma_Q= (C,q_{\min},q_{\max}). \] Its merge is not simply a vector sum, but: ```text count = sum first = first nonempty child first last = last nonempty child last ``` Thus: \[ \boxed{ \oplus_Q } \] may be any registered, verifiable merge algebra. --- # 8. Knowledge State DMSD v1 defines: ```text UNKNOWN ESTIMATED PROBABLE EXACT_COMPUTED EXACT_MERGED EXACT_CERTIFIED ``` These states are not merely "truth values". They describe: \[ \boxed{ \text{Epistemic Admission State}. } \] --- # 9. Exact States The exact family: \[ \mathcal K_{\rm exact} = \{ \texttt{EXACT\_COMPUTED}, \texttt{EXACT\_MERGED}, \texttt{EXACT\_CERTIFIED} \}. \] All of them require exactness in the target semantics; the difference is in provenance: - direct computation； - exact child composition； - Proof / certificate. --- # 10. No False Closure Axiom If any child exists for which: \[ K(B_i)\notin\mathcal K_{\rm exact}, \] the parent cannot be promoted merely through the exact merge rule to: \[ \texttt{EXACT\_MERGED}. \] Formally: \[ \boxed{ \exists i: K(B_i)\notin\mathcal K_{\rm exact} \Rightarrow K_{\rm merge}(B)\neq \texttt{EXACT\_MERGED}. } \] This is the: \[ \boxed{ \textbf{No False Closure Axiom}. } \] --- # 11. Baseline / Residual Model If a property observation: \[ O(B) \] has known reference structure, a baseline can be registered: \[ \beta(B). \] Residual: \[ \boxed{ R(B;\beta) = \Delta(O(B),\beta(B)). } \] Here: \[ \Delta \] may, depending on the task, be: - subtraction； - normalized residual； - likelihood residual； - divergence； - A certificate gap. A residual is therefore always: \[ \boxed{ \text{baseline-relative}. } \] It cannot be interpreted independently of baseline provenance. --- # 12. Baseline–Source Compatibility If source depth: \[ \eta \] increases, the source may gradually absorb information already explained by the baseline. The baseline should therefore be written as: \[ \beta_\eta \] rather than a fixed: \[ \beta. \] DMSD requires checking: \[ \boxed{ \text{Baseline Compatibility} ( \beta,\eta ). } \] If the source already includes the same effect, the baseline must be: - Recalibrated; - Weakened; - Or removed. --- # 13. Source Family Define a nested source family: \[ \mathcal S_\eta. \] If source depth has an ordering: \[ \eta_1\preceq\eta_2, \] one generally wants: \[ \mathcal S_{\eta_2} \] to contain task information at least as strong as that in: \[ \mathcal S_{\eta_1} \] that source. However, DMSD does not require every source family to be nested; nesting is merely a common case in the Phase 3 prime-divisibility experiments. --- # 14. Source Gain For source depth: \[ \eta, \] define a task-specific gain: \[ G(\eta). \] It may be: - ambiguity reduction； - uncertainty reduction； - certificate completion； - residual reduction； - exact coverage； - Task loss reduction. Thus: \[ \boxed{ G } \] is not restricted to representing prime-candidate elimination. --- # 15. Source Burden Define: \[ C(\eta). \] It may measure: - operation count； - wall-clock； - memory； - source predicates； - certificate bytes； - verifier cost； - energy； - External query cost. The source frontier is therefore: \[ \boxed{ \mathcal F = \{ (C(\eta),G(\eta)) \}. } \] --- # 16. Source-Efficiency Frontier If two source options: \[ \eta_1,\eta_2 \] satisfy: \[ C(\eta_1)\le C(\eta_2) \] and: \[ G(\eta_1)\ge G(\eta_2), \] with at least one strict inequality, then: \[ \eta_2 \] is dominated. Retain all nondominated source options: \[ \boxed{ \operatorname{Pareto}(\mathcal F). } \] --- # 17. Budgeted Source Policy For the blocks: \[ B_1,\ldots,B_m, \] each block has its own source menu: \[ \mathcal F_i. \] Given task weights: \[ w_i \] and a budget: \[ B, \] solve: \[ \boxed{ \max_{\eta_1,\ldots,\eta_m} \sum_iw_iG_i(\eta_i) } \] subject to: \[ \boxed{ \sum_iC_i(\eta_i)\le B. } \] Output: \[ \Pi_B = (\eta_1,\ldots,\eta_m). \] --- # 18. Lazy Source Depth Source depth is therefore block-local: \[ \boxed{ \eta_i } \] rather than a global constant. This gives: \[ \boxed{ \text{Lazy Source Depth}. } \] alongside: \[ \boxed{ \text{Lazy Resolution}. } \] as parallel concepts. --- # 19. DMSD's Three Types of LOD v1 formally distinguishes: ## Spatial LOD \[ \rho \] How finely to look. ## Mathematical LOD \[ \sigma_Q \] How rich the summary is. ## Source LOD \[ \eta \] How deeply to know / verify. Thus: \[ \boxed{ \text{DMSD LOD} = (\rho,\Sigma_Q,\eta). } \] --- # 20. Projection Layer Visualization must not be directly equated with the core ontology. Projection: \[ V: \mathfrak D \to \mathcal Y. \] For example: - Pyramid； - Staircase； - histogram； - Frontier chart. These are all merely: \[ \boxed{ \text{Observation Projection}. } \] Changing the projection should not change the underlying block / property state. --- # 21. Provenance Every nontrivial state must be able to answer: ```text where did this value come from? what scale? what resolution? what source depth? which property layer? which baseline? which method? which certificate? which parent / children? ``` Thus: \[ \mathcal H \] is not additional metadata, but a formal member of the DMSD Core. --- # 22. DMSD v1 Core Axioms --- ## A1 — Partition Soundness \[ B=\bigsqcup_iB_i. \] --- ## A2 — Scale Extensibility As long as the scale grammar defines a rule for generating the next level, a finite runtime does not restrict the theoretical domain from extending further. --- ## A3 — Exact Summary Composition If a property layer declares a merge algebra, a verifier must be able to reconstruct the exact parent summary from exact children. --- ## A4 — No False Closure A non-exact child must not be used to smuggle an exact parent through a merge. --- ## A5 — Projection Separation \[ \text{Projection Change} \not\Rightarrow \text{Ontology Change}. \] --- ## A6 — Baseline Relativity A residual must be bound to baseline provenance. --- ## A7 — Baseline–Source Compatibility After source depth changes, baseline validity must be rechecked. --- ## A8 — Independent Lazy Axes \[ \rho \] and: \[ \eta \] can be increased independently. --- ## A9 — Budget Feasibility The policy output must satisfy: \[ \sum_iC_i(\eta_i)\le B. \] --- ## A10 — Finite-to-Infinite Boundary Finite validation must not automatically be promoted to a global theorem on: \[ \mathcal D_\infty \] that domain. --- # 23. Property Class Taxonomy DMSD v1 provisionally uses: ### E1 — Periodic Exact Examples: ```text parity mod m ``` ### E2 — Boundary-Analytic Exact Example: ```text perfect squares ``` ### E3 — Computed Exact Requires actual computation on the block. ### E4 — Certificate Exact Depends on a proof object / verifier. ### A1 — Approximate / Estimated Carries: ```text error model scope baseline ``` ### P1 — Probable Carries: ```text algorithm risk semantics scope ``` A property can support multiple admission paths simultaneously. --- # 24. Boundary Between Core and Plugins The following belong to the Core: - Scale Grammar; - Block; - Refinement; - Knowledge State; - PropertyLayer protocol; - Summary Algebra protocol; - Baseline protocol; - Source Frontier; - Budget Policy; - Provenance. The following do not belong to the Core: ```text prime square parity mod 7 PNT W30030 trial division decimal base ``` They are all: \[ \boxed{ \text{Plugins / Registered Instances}. } \] --- # 25. The Role of the Prime Phase The Prime Phase has not been deleted. It has now become: \[ \boxed{ \text{DMSD Reference Stress Test A}. } \] It validated: - UNKNOWN state; - exact computed / merged； - baseline / residual； - representation audit； - source depth； - source burden； - Budgeted policy. These capabilities themselves, however, have been abstracted away from prime ontology. --- # 26. Formal Runtime Interface This package provides: ```text dmsd_core.py ``` containing: ```text ScaleGrammar Block SummaryEnvelope PropertyLayer KnowledgeState SourceOption SourceFrontier BudgetPolicy split_block() verify_partition() ``` This is not a production runtime, but the reference implementation of Formal Core v1. --- # 27. Schema This package provides: ```text dmsd_core_schema.json ``` formally recording: - Scale grammar; - Block; - Knowledge envelope; - Property layer; - Source frontier; - Policy. The purpose is not to claim that the schema is definitively fixed, but to enable compatibility / migration in later versions. --- # 28. Validation Generalized randomized validation: ```text Partition trials: 500 Parity merge trials: 300 Residue mod-7 merge trials: 300 Square structured merge trials: 300 Prime exact merge trials: 250 Unknown-gate cases: 3 Source frontier trials: 300 Budget policy trials: 250 ``` All: ```text PASS ``` A total of: \[ \boxed{ 2203 } \] registered validation cases / gates. --- # 29. Runtime Self-Validation The reference module itself also underwent a direct import / execution audit: ```text module import: PASS ScaleGrammar: PASS Block partition: PASS Parity plugin compute: PASS Exact merge: PASS UNKNOWN merge gate: PASS SourceFrontier: PASS BudgetPolicy: PASS ``` Formal Core is therefore not merely a documentary definition, but can be instantiated directly in Python. --- # 30. A Minimal Usage Workflow ```text 1. register ScaleGrammar 2. create Block 3. refine Block if needed 4. attach PropertyLayer 5. compute / estimate / certify summary 6. store KnowledgeState 7. merge exact children when admissible 8. attach Baseline if needed 9. compute Residual if needed 10. register SourceFrontier 11. allocate Source Depth under Budget 12. preserve Provenance ``` --- # 31. Shortest Definition DMSD v1 condensed into one sentence: \[ \boxed{ \text{A serializable runtime in which mathematical domains, resolution, knowledge depth and computational burden can all expand locally on demand.} } \] --- # 32. Comparison with the Initial Concept Initially: a decimal pyramid, a staircase, upward / downward traversal and local zoom, as the unchanged source literal below says: ```text 十進制金字塔 + 階梯 + 往上 / 往下 + 局部 zoom ``` Now it has become: ```text Scale Grammar + Block Refinement + Projection + Property Summary Algebra + Knowledge State + Baseline / Residual + Source Depth + Source Frontier + Budget Policy + Provenance ``` In other words, the initial visualization intuition has been distilled into a property-independent core. --- # 33. Stopping Conditions for v1 Formal Core v1 stops expanding here for now. The next step should not immediately introduce new terminology again. Upgrade the Core only in the following cases: 1. A new property cannot be represented by the current protocol; 2. A counterexample to merge soundness appears; 3. Knowledge admission is insufficient; 4. Source policy needs a new formal axis; 5. Cross-runtime serialization becomes incompatible; 6. Formal proof reveals a conflict in the definitions. Otherwise, new research should prioritize: \[ \boxed{ \text{Plugin}, } \] rather than changing the Core. --- # 34. Conclusion With the completion of DMSD Phase 4, DMSD is no longer a "prime-visualization method". It is now a: \[ \boxed{ \text{Multiscale Serializable Mathematical Runtime Framework}. } \] Its core structure is: \[ \boxed{ \text{Domain} \times \text{Resolution} \times \text{Property} \times \text{Knowledge} \times \text{Source} \times \text{Burden}. } \] The two most important lazy principles are: \[ \boxed{ \text{Compute only what you need to see} } \] and: \[ \boxed{ \text{Know deeply only what you need to certify}. } \] --- ```text DMSD Phase 4: COMPLETE Generalized Formal Core v1: FROZEN FOR VALIDATION Prime Phase: demoted from Core to Reference Stress Test A Next recommended: cross-property / cross-runtime validation before any Core v1.1 expansion ```