{"slug": "my-name-is-simon", "title": "My Name Is SiMON", "summary": "FSL, a governed symbolic language for making autonomous-agent claims inspectable, has released version 1.1.8 of its public package, which includes 32 theorem records with 31 machine-checked by Lean 4 and one under explicit axioms. The package provides a formal evidence bundle for reviewing mathematical claims about bounded observers in spatial/temporal systems, aiming to replace vague agent assertions with stable, named, reviewable objects.", "body_md": "FSL is a governed symbolic language for making autonomous-agent claims inspectable.\n\nThis repository is the public package for FSL and the governed bounded observer theorem stack. It explains a model of agents as bounded observers in a spatial/temporal system, publishes theorem and proof-status evidence, and provides machine-readable language exports that external tools can inspect.\n\nCurrent public package version: `1.1.8`\n\nThis package should be read first as a formal evidence bundle, then as a symbolic language/adoption package.\n\nStart here if you are reviewing the mathematical and evidence claims:\n\n`formal_whitepaper.md`\n\nstates the theorem-by-theorem proof-status boundary.`THEOREM_REGISTRY.md`\n\nand`theorem_registry.json`\n\nidentify the 32 public theorem records.`lean_coverage_report.md`\n\nand`lean_coverage.json`\n\nreport 31 machine-checked theorem records and 1 machine-checked-under-axioms record.`ASSUMPTIONS_APPENDIX.md`\n\nand`CRYPTO_AXIOM_BOUNDARY.md`\n\nexplain the declared axioms and the named cryptographic binding assumption.`REPLAY_MATRIX.md`\n\n,`replay_matrix.json`\n\n, and`scripts/replay_fsl_claim.py`\n\nshow how a reviewer can replay one public theorem claim.`theorem_lifecycle.json`\n\nrecords public lifecycle status; it is evidence of theorem-record publication state, not a substitute for Lean proof.`CHECKSUMS.sha256`\n\nverifies that the exported package artifacts have not drifted.\n\nOnly after that formal evidence path should a reader move to the broader FSL language, role-governance, Rust parity, semantic file object, repository-ingestion, and validated-event-kernel material. Those layers explain adoption and runtime context; they do not strengthen theorem proof status.\n\n| Evidence surface | Current public status |\n|---|---|\n| Theorem records | 32 public records |\n| Lean proof status | 31 machine-checked, 1 machine-checked under explicit axioms |\n| Open proof holes | 0 scanned code-level `sorry` /`admit` holes |\n| Declared axioms | 132 public assumptions/model primitives |\n| Central result | `gbo_v_underdetermination` and `anchor_nonuniqueness_exists` |\n| Cryptographic boundary | `gbo_vi_non_equivocating` under a named binding assumption |\n| Lifecycle status | 32 active public theorem lifecycle records |\n| Replay layer | Per-claim replay through `scripts/replay_fsl_claim.py` |\n| Runtime event layer | Typed, UI-agnostic event evidence; not governance authority |\n| Runtime authority | Rust remains narrowly scoped; broad governance authority is not promoted |\n\nAI agents often describe actions with broad words like \"safe\", \"approved\", \"verified\", \"allowed\", or \"in scope.\" Those words are useful in conversation, but too blurry for review.\n\nFor example:\n\n```\nI made the deployment change and it is verified.\n```\n\nThat can hide many different questions:\n\n- Was the agent allowed to touch those files?\n- Did it stay inside scope?\n- Was anything formally proved?\n- Was the proof checked by Lean 4, or checked under assumptions?\n- Was the result only tested by runtime parity?\n- Did the release artifact drift after export?\n- Can another reviewer replay the claim without trusting the author's summary?\n\nFSL separates those claims into stable, named, reviewable objects.\n\nThis package connects five layers:\n\n``` php\nHTM manifold\n  -> governed bounded observer\n  -> Lean theorem evidence\n  -> SiMON governance/runtime evidence\n  -> FSL semantic references\n```\n\nThe spatial substrate is an HTM, or Hierarchical Triangular Mesh, surface.\n\nIn plain terms, the system divides a spherical surface into addressable cells. Cells can have neighbors, parents, children, and movement relations. This gives the model a way to talk about where an observer is, what local region it can inspect, and how it can move without pretending it sees everything.\n\n```\nAn agent acts from somewhere. It does not have global vision.\n```\n\nA governed bounded observer is an agent modeled with limits.\n\nIt has:\n\n- identity;\n- position or local state;\n- visible neighborhood;\n- movement rule;\n- time/history constraint;\n- governance boundary;\n- record of what claims it is allowed to make.\n\nThe observer model asks:\n\n- What can this agent see?\n- Where may it move?\n- What history must it preserve?\n- What scope is it allowed to act inside?\n- What claims can be supported by evidence?\n\nLean 4 is a proof checker.\n\nA theorem is a precise claim that a proof checker can verify from definitions and allowed assumptions.\n\nInstead of only saying:\n\n```\nThe observer preserves valid history.\n```\n\nthis package gives the claim a theorem record, stable theorem ID, Lean declaration when available, proof status, assumption boundary, lifecycle status, and release checksums.\n\nThis package includes:\n\n- 32 public theorem records;\n- 31 machine-checked theorem records;\n- 1 machine-checked-under-axioms record;\n- 0 partial records;\n- 0 definition-only records;\n- 0 planned records;\n- 132 declared Lean axioms;\n- 0 code-level\n`sorry`\n\nor`admit`\n\nproof holes; - 32 active theorem lifecycle records.\n\nThe one axiom-dependent theorem is `gbo_vi_non_equivocating`\n\n. Its boundary is documented in `CRYPTO_AXIOM_BOUNDARY.md`\n\n.\n\nThe strongest public-facing result is the underdetermination family:\n\n`gbo_v_underdetermination`\n\n`anchor_nonuniqueness_exists`\n\nThese theorems capture the core bounded-observer point: a local observer can have evidence that is consistent with more than one possible world state or semantic anchor. In plain English, the system does not merely say \"the agent is bounded.\" It proves that bounded evidence can leave genuine ambiguity.\n\nThe package separates theorem evidence into different classes:\n\n| Class | Meaning | Example |\n|---|---|---|\n| Structural Lean theorem | A checked statement about the model's structure, motion, cost, horizon, or ambiguity. | `gbo_v_underdetermination` |\n| Model-definition consequence | A checked consequence that follows closely from the definitions and is useful as a sanity check. | decomposition and preservation lemmas |\n| Cryptographic-assumption theorem | A checked theorem that depends on an explicit external cryptographic binding assumption. | `gbo_vi_non_equivocating` |\n| Runtime/evidence lifecycle claim | Evidence that a claim was exported, attested, replayable, or checksummed. | lifecycle records, replay matrix, checksum manifest |\n\nThose classes should not be collapsed into one vague claim of \"verified.\" A Lean theorem, an axiom-dependent theorem, a lifecycle attestation, a Rust parity check, and a checksum are different kinds of evidence.\n\nFSL uses step-admissibility for local observer, file, and governance-transition claims. A step-admissible transition is acceptable for the current bounded step.\n\nThat is not the same as whole-trajectory admissibility. The current package does not claim to prove that an agent's entire future path remains globally viable, that cumulative burden is exhausted or preserved across all future actions, or that Rust owns those decisions.\n\nAn axiom is an explicit assumption or model primitive that the proof checker is allowed to use.\n\nThat is different from an unfinished proof.\n\n| Term | Plain meaning | In this package |\n|---|---|---|\n| Theorem | A claim checked by the proof system. | A stable theorem record with proof status and evidence links. |\n| Axiom | An explicit assumption or model boundary. | Publicly inventoried in `ASSUMPTIONS_APPENDIX.md` and `lean_assumptions.json` . |\n| Proof hole | An unfinished proof placeholder such as `sorry` or `admit` . |\nCount is 0 for scanned code-level Lean proof holes. |\n\nThe `132`\n\ndeclared axioms are not 132 hidden failed proofs. They are the visible assumption inventory across scanned Lean files, including governance model bridge files.\n\nThe SHA-256-related boundary is intentionally narrow: this package treats cryptographic binding as a named assumption for the commitment theorem. It does not claim that Lean proves SHA-256 collision resistance.\n\nSiMON is the governed runtime and research system from which this public package was exported.\n\nThe full private/runtime system contains mission lifecycle records, governance execution, StateProof chain material, runtime code, and broader experimental surfaces. This repository is not the full runtime. It is the public evidence and language package.\n\nThat separation is intentional. A reader should be able to inspect theorem records, proof boundaries, FSL exports, replay artifacts, and checksums without access to the private SiMON repository.\n\nThe validated event kernel is the runtime-facing event model around FSL.\n\nIt treats interface input, role outputs, FSL references, theorem references, traversal evidence, FileInspector context, Builder-readiness signals, Governor decisions, release evidence, and StateProof candidates as typed events. Those events can be replayed and inspected without pretending that a UI panel, chat message, Rust preflight, or StateProof candidate is governance authority.\n\nThe intended path is:\n\n``` php\nany interface\n  -> typed runtime event\n  -> shape and authority-boundary checks\n  -> FSL/theorem/evidence references\n  -> Python/governance interpretation\n  -> optional StateProof candidate\n  -> Governor boundary before durable consequence\n```\n\nThe old SiMON chat UI is not the target runtime architecture. It is only a source of useful interaction concepts such as prompt intake, governance status visibility, FSL references, role-pipeline visibility, and replay visibility. The public runtime model is UI-agnostic: chat, CLI, API, repository ingestion, or future visual manifold tools can submit typed events without inheriting old chat-local authority.\n\nFor the dedicated public explainer, see `VALIDATED_EVENT_KERNEL.md`\n\n.\n\nImportant boundary:\n\n```\ntyped runtime event != governance authorization\nvalidated event trace != StateProof append\nRust preflight pass != proof or permission\nUI visibility != authority\n```\n\nSiMON's reference governance system uses roles to keep action, inspection, authorization, and evidence separate.\n\nIn public terms:\n\n| Role | Public meaning | FSL-facing claim |\n|---|---|---|\n| Research Agent | Investigates current state and evidence before action. | What is known, unknown, or queryable. |\n| Scope Agent | Bounds the proposed work before implementation. | Which files, packages, and deltas are in scope. |\n| File Inspector | Reads allowed files without changing them. | What the authorized scope actually contains. |\n| Builder | Performs the scoped implementation. | What changed inside the allowed boundary. |\n| Governor | Authorizes or rejects durable governance transitions. | Which transition is allowed to become governance evidence. |\n| Commander | Owns mission-level authority in the reference system. | Which mission-level action may proceed. |\n\nFSL does not replace these roles. FSL gives stable names to the claims those roles produce. A scope boundary can be referenced as a declared scope. A builder delta can be referenced as a symbolic change. A Governor decision can be referenced as an authorization boundary. A StateProof can be referenced as a durable evidence class.\n\nRust is being developed as a kernel/runtime hardening layer for selected governance checks. In this release, Rust is not the governance authority. Rust has one active narrow preflight boundary: it may reject malformed serialized FSL semantic records before Python/query-surface authority evaluates surviving records. Rust also mirrors selected StateProof candidate, append-gate, file-semantics, repository semantic, and role-bridge validation boundaries as shadow parity, helping detect malformed serialized records, policy drift, scope mismatch, and authority-escalation attempts.\n\nThe intended long-term value of a Rust kernel is type-safe enforcement at carefully promoted boundaries. Promotion requires explicit evidence, compatibility checks, rollback rules, and a governed authority decision. Role-bridge malformed-packet rejection is currently decision-scoped for future promotion only; it is not active runtime authority. Until a boundary is explicitly promoted, Rust remains evidence-bearing validation, not constitutional authority.\n\nThe current FSL runtime also models repository files as semantic objects.\n\nThat means a file is not only treated as bytes on disk. It can be described by:\n\n- repository path;\n- file kind;\n- semantic role;\n- language or format;\n- allowed operation class;\n- RFC 2119-style constraints;\n- expected scope relationship;\n- dependency and invariant context;\n- advisory step-admissibility status;\n- public constraint catalog reference.\n\nThis layer helps bridge ordinary repository work to FSL meaning. A markdown paper, a Lean theorem file, a Rust runtime module, a checksum file, and a public export manifest do not carry the same governance meaning. They have different roles, different risks, different allowed operations, and different evidence boundaries.\n\nIn the reference SiMON runtime, ScopeAgent can express what kinds of files are expected, FileInspector can attach read-only context to allowed files, and the advisory file step-admissibility layer can classify a proposed file action as eligible, rejected, requiring Governor review, or not applicable.\n\nImportant boundary:\n\n```\nsemantic file classification is not enforcement authority\nadvisory step-admissibility is not Builder rejection authority\nRust file-semantics parity is not governance authority\n```\n\nThe practical value is that a governed agent can reason about files with more precision than \"this path is allowed.\" It can distinguish the meaning of the file, the constraints attached to that kind of file, and the evidence needed before a change should proceed.\n\nThe public catalog for those constraints is included as `FILE_CONSTRAINT_CATALOG.md`\n\nand `file_constraint_catalog.json`\n\n. It turns stable constraint references into readable RFC 2119-style statements without granting enforcement authority.\n\nThe repository semantic ingestion layer extends file semantics from one file at a time to a whole repository snapshot.\n\nThe bridge is staged:\n\n``` php\nrepository files\n  -> file inventory\n  -> path and content classification\n  -> repository profile override\n  -> semantic file object\n  -> constraint resolution\n  -> dependency and invariant context\n  -> advisory step-admissibility\n  -> HTM semantic placement\n  -> bounded observer traversal\n  -> optional StateProof candidate\n  -> optional Rust shadow parity\n```\n\nThe point is not only to know that a path exists. The point is to know what kind of meaning the file carries in the governed system. A public README, a release note, a Lean proof snapshot, a Rust runtime module, and a checksum manifest should not be treated as interchangeable files.\n\nIn this model, each file can become a semantic object. That object can then be placed into the HTM/FSL manifold as a semantic-layer occupant. A bounded observer can traverse the resulting semantic map, and FileInspector can attach read-only context about visible files, constraints, dependencies, and ambiguity sources.\n\nImportant boundary:\n\n```\nsemantic ingestion is not permission to edit\nHTM placement is not observer movement\nbounded traversal is not durable proof\nStateProof candidate is not StateProof append\nRust repository semantic parity is not governance authority\n```\n\nFor the dedicated public explainer, see `REPO_SEMANTIC_INGESTION.md`\n\n.\n\nFSL is the semantic language layer connecting these pieces.\n\nIt gives stable names to claims that would otherwise remain loose prose. A mission, theorem, proof status, assumption boundary, runtime boundary, release artifact, and external software identifier can all be connected through shared symbolic references.\n\n| Ordinary context | Project artifact | FSL / theorem reference | Meaning |\n|---|---|---|---|\n| Work request | mission or update packet | `mission_open` , `declared_scope` |\nA bounded mission exists and declares what may change. |\n| Changed files | commit or file delta | `Δ_FSL` , `⊕_sync` |\nSymbolic/export state changed and synchronized. |\n| Allowed scope | `allowed_packages` |\n`declared_scope` |\nThe agent may act only inside the declared boundary. |\n| Agent identity | DID and StateProof identity | `DID` , `identity` , `StateProof` |\nObserver identity is tracked across history. |\n| Spatial position | HTM cell or observer location | `space.htm_surface` , `adjacent` |\nThe observer acts from a location on the manifold. |\n| Movement rule | movement/history packet | `valid_spatial_motion` , `valid_motion_stay` |\nMotion obeys the HTM neighbor/bounded-motion rule. |\n| History rule | trace or tick sequence | `valid_history_preserved` , `tick` |\nValid history persists across a step-admissible motion. |\n| Observer bound | local view or horizon | `gbo_iii_spatial_horizon` , `bounded` |\nThe observer has a bounded spatial horizon. |\n| Temporal bound | tick/time horizon | `gbo_iii_temporal_horizon` , `time` |\nThe observer has a bounded temporal horizon. |\n| Formal proof reference | Lean declaration | `gbo_vi_non_equivocating` |\nThe theorem is checked under explicit cryptographic assumptions. |\n| Release integrity | checksum file | `CHECKSUMS.sha256` |\nPackage files can be checked for byte-level drift. |\n\nThe point of FSL is not decorative notation. It is durable meaning that humans and tools can review.\n\nRecent hardening work added a governed path from semantic observation to durable evidence.\n\nThe internal pipeline is:\n\n``` php\nobservable semantics\n  -> StateProof anchor candidate\n  -> anchor decision\n  -> append request\n  -> dry-run StateProof payload\n  -> Governor authorization\n  -> controlled append integration\n  -> Rust shadow parity\n```\n\nImportant boundary:\n\n```\nCandidate evidence is not StateProof evidence.\nDry-run payload is not StateProof append.\nGovernor authorization is not direct append execution.\nRust parity is not governance authority.\n```\n\nThe canonical StateProof append entrypoint remains:\n\n```\ngovernance.identity.state_proof.generate_state_proof\n```\n\nRust currently mirrors candidate and append-gate validation as shadow parity only. It can help detect malformed records and authority escalation attempts, but it is not promoted to authority for StateProof decisions.\n\nRust also mirrors file semantic classification and advisory step-admissibility status as shadow parity. That check can classify a path into a file kind and semantic role, compare expected scope metadata, inspect supplied constraint-evaluation summaries, and report whether the serialized record looks eligible, rejected, or requiring Governor review. It still cannot reject the Builder, expand scope, authorize governance, append StateProof, or promote Rust authority.\n\nRust also mirrors repository semantic records as shadow parity. That check can validate supplied semantic object, placement, and advisory-status summaries for drift or authority escalation. It still does not scan repositories by itself, own FileInspector context, reject Builder actions, expand scope, authorize governance, append StateProof, or promote Rust authority.\n\nRust also mirrors role-bridge packets as shadow parity. That check covers serialized ScopeAgent semantic regions, TourAgent traversal results, FileInspector context maps, Builder readiness packets, and Governor durable consequence decisions. It can reject malformed or authority-escalating serialized role-bridge packets in parity fixtures, but the future active gate for that surface has not been promoted. Rust still cannot authorize missions, move observers, own role outputs, override Governor, reject Builder work, expand scope, or append StateProof evidence.\n\nSee:\n\n`RUST_PARITY_NOTE.md`\n\n`RUST_AUTHORITY_CRITERIA.md`\n\n`docs/fsl_rust_authority_promotion_audit.md`\n\nFrom the public package directory:\n\n```\npython3.12 scripts/replay_fsl_claim.py gbo_iii_temporal_horizon\n```\n\nFor an axiom-dependent example:\n\n```\npython3.12 scripts/replay_fsl_claim.py gbo_vi_non_equivocating\n```\n\nTo list available theorem IDs:\n\n```\npython3.12 scripts/replay_fsl_claim.py --list\n```\n\nThe replay script is not a Lean prover and not a governance authority. It helps a reviewer traverse one public claim from theorem ID to evidence boundary.\n\nIf a repository semantic map export is available, replay it with:\n\n```\npython3.12 scripts/replay_repo_semantic_map.py semantic_map.json\n```\n\nThat command checks the exported semantic map for replay/placement drift. It does not scan a live repository, authorize edits, append StateProof evidence, or promote Rust authority.\n\nIf you are new to this repository:\n\n- Read this README.\n- Read\n`USE_CASES.md`\n\nfor the governed production-change journey. - Read\n`REPO_SEMANTIC_INGESTION.md`\n\nto understand how repository files become semantic objects in the HTM/FSL manifold. - Read\n`EVIDENCE_CLASSES.md`\n\nto understand evidence boundaries. - Replay one theorem claim with\n`scripts/replay_fsl_claim.py`\n\n. - Inspect\n`THEOREM_REGISTRY.md`\n\nor`theorem_registry.json`\n\n. - Read\n`formal_whitepaper.md`\n\nfor theorem-by-theorem proof status. - Map your own system names, such as tickets, commits, policies, CI jobs, deployment IDs, or audit records, to FSL-style semantic references.\n\nThis package is:\n\n- a public, versioned release of the FSL language and observer theorem evidence bundle;\n- a formal proof-status package for 32 public theorem records;\n- a replayable evidence package with checksums;\n- a bridge between governed autonomous-agent action and inspectable semantic claims;\n- a public explanation of repository files as semantic objects placed into an HTM/FSL manifold;\n- a publication package containing human-readable and machine-readable artifacts.\n\nThis package is not:\n\n- a full autonomous-agent runtime;\n- a production deployment framework;\n- a replacement for Lean;\n- a replacement for governance execution;\n- a runtime authority handoff to Rust;\n- a claim that generated exports are parser authority;\n- a claim that Rust can append StateProofs;\n- a claim that every governance axiom has been derived from first principles;\n- a claim that every real-world implementation detail is formally proved.\n\n- FSL symbols: 179\n- FSL bundles: 15\n- FSL tiers: A 94, B 70, C 8, D 7\n- Glyph candidates: 25\n- Glyph promotion state: 3 promotable now, 22 requiring alias plans\n- Observer kernel theorem records: 32 of 32 complete\n- Lean coverage snapshot: 31 checked theorem records, 1 axiom-dependent, 0 partial, 0 definition-only, 0 planned\n- Theorem lifecycle snapshot: 32 active records\n- Lean assumptions snapshot: 132 declared axioms, 0 code-level\n`sorry`\n\n/`admit`\n\nproof holes - FSL file-semantics layer: semantic classification and advisory step-admissibility only\n- FSL file constraint catalog: public vocabulary/evidence only\n- FSL repository semantic ingestion: semantic map/replay explanation only\n- Rust StateProof candidate parity: shadow only\n- Rust append-gate parity: shadow only\n- Rust file-semantics parity: shadow only\n- Rust repository semantic parity: shadow only\n- Rust role-bridge parity: shadow only\n- Rust semantic-record malformed rejection: active reject-only preflight\n- Rust role-bridge malformed rejection: decision-scoped only, not active\n- Broad Rust authority promotion: not granted\n\nFor a compact overview:\n\n`ABSTRACT.md`\n\nFor examples and conceptual walkthroughs:\n\n`USE_CASES.md`\n\n`REPO_SEMANTIC_INGESTION.md`\n\nFor evidence boundaries:\n\n`EVIDENCE_CLASSES.md`\n\n`INDEPENDENT_REPLAY.md`\n\n`FILE_CONSTRAINT_CATALOG.md`\n\n`file_constraint_catalog.json`\n\n`REPLAY_MATRIX.md`\n\n`replay_matrix.json`\n\n`scripts/replay_fsl_claim.py`\n\n`scripts/replay_repo_semantic_map.py`\n\nFor theorem and proof-status review:\n\n`whitepaper.md`\n\n`formal_whitepaper.md`\n\n`THEOREM_REGISTRY.md`\n\n`theorem_registry.json`\n\n`theorem_lifecycle.json`\n\n`lean_coverage_report.md`\n\n`lean_coverage.json`\n\n`ASSUMPTIONS_APPENDIX.md`\n\n`lean_assumptions.json`\n\n`FORMAL_PROOF_BUNDLE.md`\n\n`CRYPTO_AXIOM_BOUNDARY.md`\n\nFor FSL language review:\n\n`fsl_governed_symbolic_language.md`\n\n`fsl_specification.md`\n\n`fsl_registry.json`\n\n`fsl_types.json`\n\n`fsl_grammar.json`\n\n`fsl/SYSTEM.yaml`\n\n`FILE_CONSTRAINT_CATALOG.md`\n\n`file_constraint_catalog.json`\n\nFor release and runtime boundaries:\n\n`RELEASE_NOTES.md`\n\n`RELEASE_POLICY.md`\n\n`RELEASE_CANDIDATE_AUDIT.md`\n\n`PUBLICATION_TAG.md`\n\n`STATEPROOF_NOTE.md`\n\n`RUST_PARITY_NOTE.md`\n\n`RUST_AUTHORITY_CRITERIA.md`\n\n`docs/fsl_rust_authority_promotion_audit.md`\n\n`PUBLIC_REPO_NOTES.md`\n\nFor PDF presentation:\n\n`OVERLEAF_README.md`\n\n`overleaf/main.tex`\n\n`overleaf/references.bib`\n\n`README.md`\n\n: public landing page and orientation map`ABSTRACT.md`\n\n: compact overview for first-time readers`USE_CASES.md`\n\n: practical adoption scenarios and governed autonomous-agent example`REPO_SEMANTIC_INGESTION.md`\n\n: public explainer for repository semantic objects, HTM placement, bounded traversal, StateProof candidates, and Rust shadow parity`EVIDENCE_CLASSES.md`\n\n: distinctions between proof, attestation, export, parity, authorization, checksum, and StateProof evidence`FILE_CONSTRAINT_CATALOG.md`\n\n: human-readable RFC 2119-style file constraint catalog`file_constraint_catalog.json`\n\n: machine-readable file constraint catalog`INDEPENDENT_REPLAY.md`\n\n: reviewer playbook for traversing theorem claims to evidence`scripts/replay_fsl_claim.py`\n\n: one-theorem public replay command`scripts/replay_repo_semantic_map.py`\n\n: semantic-map replay command for exported repository semantic maps`REPLAY_MATRIX.md`\n\n: human-readable theorem-by-theorem replay index`replay_matrix.json`\n\n: machine-readable theorem-by-theorem replay index`whitepaper.md`\n\n: governed bounded observer theorem position paper`formal_whitepaper.md`\n\n: formal proof-status whitepaper`OVERLEAF_README.md`\n\n: Overleaf upload and compile instructions`overleaf/`\n\n: PDF-ready LaTeX paper source`STATEPROOF_NOTE.md`\n\n: public explanation of raw-chain status and repaired canonical verification`RUST_PARITY_NOTE.md`\n\n: public explanation of Rust/Python parity status and current authority boundary`RUST_AUTHORITY_CRITERIA.md`\n\n: public criteria for future Rust governance-authority promotion`docs/fsl_rust_authority_promotion_audit.md`\n\n: report-only audit explaining why Rust remains shadow parity`THEOREM_REGISTRY.md`\n\n: human-readable observer theorem registry`theorem_registry.json`\n\n: machine-readable observer theorem registry`theorem_lifecycle.json`\n\n: machine-readable public theorem lifecycle export`lean_coverage_report.md`\n\n: human-readable Lean coverage audit`lean_coverage.json`\n\n: machine-readable Lean coverage audit`ASSUMPTIONS_APPENDIX.md`\n\n: human-readable no-sorry/no-axiom audit`lean_assumptions.json`\n\n: machine-readable Lean assumption inventory`FORMAL_PROOF_BUNDLE.md`\n\n: guide to the public formal proof bundle`lean/`\n\n: public Lean source snapshots used by coverage and assumptions audits`CRYPTO_AXIOM_BOUNDARY.md`\n\n: public assumption boundary for the axiom-dependent commitment theorem`FORMAL_COVERAGE_BASELINE.md`\n\n: formal-whitepaper-track proof-status baseline`fsl_governed_symbolic_language.md`\n\n: FSL language paper`fsl_specification.md`\n\n: human-readable FSL specification`fsl_registry.json`\n\n: machine-readable symbol registry`fsl_types.json`\n\n: machine-readable type, sort, and category export`fsl_grammar.json`\n\n: machine-readable grammar and rendering export`fsl/SYSTEM.yaml`\n\n: canonical FSL source snapshot`MANIFEST.md`\n\n: include/reference/exclude manifest`PACKAGE_MAP.md`\n\n: layer map connecting papers, exports, and provenance`RELEASE_NOTES.md`\n\n: release contents and verification notes`RELEASE_POLICY.md`\n\n: versioning, compatibility, and publication policy`RELEASE_CANDIDATE_AUDIT.md`\n\n: claim-safety and public-boundary audit`ERRATA.md`\n\n: horizon correction and spatial-horizon resolution`HORIZON_RECONCILIATION.md`\n\n: governed reconciliation note for the horizon lifecycle gap`PUBLICATION_TAG.md`\n\n: governed release-freeze and tag-ready record`VERSION`\n\n: current public package version`EXPORT_MANIFEST.json`\n\n: allowlisted source map for rebuilding this package from the SiMON source tree`PUBLIC_REPO_NOTES.md`\n\n: public repository boundary and exclusions`CHECKSUMS.sha256`\n\n: SHA-256 checksums for repository artifacts\n\nFrom the SiMON source tree, the public package can be refreshed with:\n\n```\npython3.12 scripts/export_public_fsl_package.py --check\n```\n\nThe exporter uses `EXPORT_MANIFEST.json`\n\n, regenerates theorem registry exports, preserves repository metadata, refuses excluded private/runtime paths, copies the replay script, and rewrites `CHECKSUMS.sha256`\n\n.\n\nFrom the public package directory, run:\n\n```\nshasum -a 256 -c CHECKSUMS.sha256\n```\n\nEvery listed file should return `OK`\n\n.", "url": "https://wpnews.pro/news/my-name-is-simon", "canonical_source": "https://github.com/ProphetGang/formal_symbol_language", "published_at": "2026-07-08 06:41:49+00:00", "updated_at": "2026-07-08 06:59:58.193124+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-research", "ai-tools", "ai-ethics"], "entities": ["FSL", "SiMON", "Lean 4", "HTM", "Hierarchical Triangular Mesh"], "alternates": {"html": "https://wpnews.pro/news/my-name-is-simon", "markdown": "https://wpnews.pro/news/my-name-is-simon.md", "text": "https://wpnews.pro/news/my-name-is-simon.txt", "jsonld": "https://wpnews.pro/news/my-name-is-simon.jsonld"}}