vrr/WFGY
2
0
Fork 0
mirror of https://github.com/onestardao/WFGY.git synced 2026-05-01 21:11:11 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
WFGY/TensionUniverse/EventHorizon/README.md
PSBigBig × MiniPS a62aaa733a
Update README.md
2026-02-10 17:54:00 +08:00

33 KiB
Raw Blame History

🧭 Lost or curious? Open the WFGY Compass

WFGY System Map

(One place to see everything; links open the relevant section.)

Layer Page What it’s for
🧠 Core WFGY 1.0 The original homepage for WFGY 1.0
🧠 Core WFGY 2.0 The symbolic reasoning engine (math and logic)
🧠 Core WFGY 3.0 The public viewing window for WFGY 3.0 Singularity demo. 🔴 YOU ARE HERE 🔴
🗺️ Map Problem Map 1.0 16 failure modes plus fixes
🗺️ Map Problem Map 2.0 RAG focused recovery pipeline
🗺️ Map Semantic Clinic Symptom → family → exact fix
🧓 Map Grandma’s Clinic Plain language stories mapped to PM 1.0
🏡 Onboarding Starter Village Guided tour for newcomers
🧰 App TXT OS .txt semantic OS, 60 second boot
🧰 App Blah Blah Blah Abstract and paradox Q and A built on TXT OS
🧰 App Blur Blur Blur Text to image with semantic control
🧰 App Blow Blow Blow Reasoning game engine and memory demo
🧪 Research Semantic Blueprint Modular layer structures for future work
🧪 Research Benchmarks Comparisons and how to reproduce
🧪 Research Value Manifest Why this engine creates value at scale

💥 WFGY 3.0 · Singularity Demo 💥

W3

Where to go from here

If you only have a short amount of time, choose one of these paths:

Before you start:

If it works, nothing before it matters.

120s quickstart

  1. Download (TXT) WFGY 3.0 Singularity demo TXT file

    Download from GitHub. Optional: verify checksum manually (Colab)

  2. Upload

    Upload the TXT pack to a high capability model. Enable reasoning mode if the platform supports it.

  3. Run

    Type run to see the menu, then say go when prompted.

🔬 demo preview (10s GIF)

WFGY 3.0 Singularity Demo

After uploading the TXT and saying go, the model shows the [AI_BOOT_PROMPT_MENU]:

Choose:

  1. Verify this TXT pack online (sha256)
  2. Run the guided WFGY 3.0 · Singularity Demo for 3 problems
  3. Explore WFGY 3.0 · Singularity Demo with suggested questions
🔬 Colab tools (checksum and Q130 experiments)

Verify checksum manually (sha256, Colab):
Open in Colab

Use this when automated verification is unavailable.


Early Tension Universe · Q130 effective layer experiments.
Both notebooks are single cell scripts. They install dependencies, explain the setup, prompt you to provide an API key locally in Colab, then run the full experiment and print tables and plots.
No fine tuning. Only encoding and scoring changes.

This section will expand as more TU experiments come online.

Tension Universe · BlackHole S problem collection

This folder is the public viewing window for WFGY 3.0 Singularity demo.
It is not a loose set of notes. It is a frozen, versioned effective layer specification of how the Tension Universe framework encodes 131 cross domain S class problems.

  • Public online date: 2026 01 31
  • Problems covered: Q001 to Q131
  • Intent: show that one tension based encoding language can survive across many hard problems without changing definitions, adding hidden parameters, or doing post hoc tuning

What you just ran in the quickstart is a reproducible entry point into this specification.

Quick navigation

Tension Universe in everyday language

If you are new here, you can think about tension in a simple way.

In real life there is good tension and bad tension.

  • Good tension is like the right stretch in a muscle, or a project that is hard but still under control. It keeps things sharp and coordinated.
  • Bad tension is like a cracked bridge or chronic stress. Forces exist but do not align. Energy is wasted and something snaps.

Modern AI systems contain both.

  • We pour data and compute into models. Some pressure becomes useful structure for reasoning and prediction. That is good tension.
  • Some pressure becomes uncontrolled and targetless. That is where hallucinations, unstable behavior, and failures appear. That is bad tension.

What Tension Universe tries to do is direct:

give a precise language for describing these tensions, then use that language to encode hard problems at the effective layer.

Instead of saying “this model seems smart” or “this metric looks fine”, we want to say:

  • here is the state space we care about
  • here are the observables and invariants that should remain stable
  • here is how good tension is stored and moved
  • here is what counts as bad tension and collapse
  • here are experiments that can tell the difference

The 131 S problems in this folder are the first large scale stress test:

  • each file takes a famous problem
  • rewrites it in tension language at the effective layer
  • attaches concrete experimental patterns that an AI system or a research lab could in principle run

What is the Singularity demo?

The Singularity demo is a public, open specification artifact inside the TU program.

  • It takes 131 S class problems across many fields.
  • It forces all of them to be written using a single set of charters and encoding rules.
  • It refuses to add ad hoc definitions per question.

You can treat this folder as the event horizon view.
You see the effective layer objects and the constraints, not the internal engine.

The production grade TU AI system and the WFGY 3.0 commercial runtime live elsewhere.
This folder is the spec and the contract that those systems must obey.

Why this is only a demo?

Tension Universe is designed as a full AI system.

  • It has its own notion of state spaces, observables, invariants, and tension fields.
  • It is meant to drive agents, training signals, and evaluation pipelines.

This repository does not expose that whole machinery. That is intentional.

This demo focuses on a single question.

If we lock ourselves to one tension language, can we still write down 131 hard problems without breaking our own rules?

So this is a demo of encoding discipline. It is not a claim of solving anything.

Repository layout

Charters

Located in ../Charters/:

These documents define the rules every S problem file must obey.

BlackHole S problem collection

All 131 problem files sit in:

Examples:

  • Q001_riemann_hypothesis.md
  • Q002_generalized_riemann_hypothesis.md
  • …
  • Q131_tension_free_energy.md

They are grouped by domain. The full navigation index is below.

TXT “book” edition and frozen snapshots

There is a TXT “book” edition of the BlackHole collection.
It is meant to be a textual snapshot of BlackHole v1 and kept in sync with that frozen edition.

Versioning rule:

  • BlackHole v1 is frozen once tagged.
  • BlackHole v2 is at most one follow up round for clarity, bug fixes, and consistency.
  • No silent patching of definitions or parameters after the fact.

Scientific position and disclaimers

What this project does not claim

  • It does not claim to prove or disprove any canonical problem.
  • It does not hide any answer as a secret field, label, or parameter.
  • It does not declare any new theorem beyond standard cited literature.

Every page is an effective layer encoding.

  • It specifies observables, invariants, and tension functionals.
  • It defines falsifiable experiments and calibration rules.
  • It describes how an AI system may use those objects as evaluation or training contracts.

It is a language for working with problems, not a proof that they are solved.

No post hoc parameter tuning

The TU charters enforce anti cheat rules.

  • Encoding classes and menus live in the charters, not in individual files.
  • Specs are meant to be published and hashed before evaluation.
  • Changing an encoding after seeing results is recorded as a failed encoding, not a success.

Versioning and non mutation policy

To keep the history auditable:

  1. Problem files are versioned and declare Last_updated.
  2. BlackHole v1 is frozen after tagging.
  3. At most one structural update wave for v2 with explicit changelogs.
  4. Changes that alter meaning must become a new version or be mediated through charters.

How to start

If you only do three things:

  1. Read the everyday explanation of tension above.
  2. Open one problem from a domain you know and one you do not.
  3. Check whether the same structure survives both without definition drift.

If that feels coherent, you are already the intended audience.

How to read a single S problem page

Each Qxxx_*.md file follows a shared template.

Typical blocks:

  1. Header metadata.
  2. Effective layer disclaimer.
  3. Canonical problem statement and status.
  4. Position in the BlackHole graph.
  5. TU encoding, state spaces, observables, invariants.
  6. Counterfactual worlds and experiments.
  7. AI and engineering spec usage notes.
  8. Roadmap and elementary explanation.
  9. TU effective layer footer with charter links and guardrails.

FAQ and participation

Join the community

You can also open GitHub issues and pull requests.

FAQ

Q1. did you solve any of these 131 problems?
No. These files describe encodings and experiments, not proofs.

Q2. what does S problem mean here?
An internal label for hard and foundational problems that can be encoded with observables and falsifiable patterns.

Q3. how is this related to WFGY and TU AI?
This folder is the public spec that can be used to test and audit reasoning behavior. The production TU AI system and WFGY 3.0 commercial runtime are out of scope here.

Q4. why should I trust definitions will not be changed quietly?
You do not need personal trust. The rules are structural. Version 1 is frozen once tagged and any version 2 changes require explicit versioning.

Q5. does the framework assume answers in advance?
It is designed to forbid baking in an answer bit. If you find any implicit assumption, report it.

Navigation index for the 131 S problems

All files live in ../BlackHole.

Quick domain jumps:

Use these links if you want to focus on a specific domain.

Q001 to Q020 · Mathematics and foundations

Back to S problem index

Q021 to Q040 · Fundamental physics and quantum matter

Back to S problem index

Q041 to Q060 · Cosmology and computation

Back to S problem index

Q061 to Q080 · Chemistry, materials and origins of life

Back to S problem index

Q081 to Q100 · Neuroscience and Earth system

Back to S problem index

Q101 to Q120 · Economics, social systems and philosophy

Back to S problem index

Q121 to Q131 · AI alignment, safety and advanced systems

Back to S problem index

More WFGY pages

If you only need the main WFGY entry pages and do not need the full Compass:

Road to WFGY 3.0 (Conceptual Evolution)

WFGY has evolved through multiple iterations, each addressing concrete limitations observed in the previous stage.
Rather than replacing earlier ideas, each version refines and generalizes the same core intuition. The goal is to make semantic deviation explicit, measurable, and controllable.

WFGY 1.x · Residual based semantic deviation

The early WFGY 1.x series focused on identifying semantic residue between an internal state and a reference or target.
Deviation was modeled as an explicit residual term, for example difference vectors or their norms. This enabled basic stability control and boundary detection.

At this stage, the emphasis was on detectability.

  • Can we tell when a system is drifting away from an intended semantic target?
  • Can this deviation be quantified in a way that supports feedback and correction?

This version established the foundational idea that semantic failure should be treated as a measurable signal, not a subjective judgment.

WFGY 2.0 · Normalized tension and unified scales

WFGY 2.0 generalized the residual concept into a normalized scalar form, often written as delta_s and bounded to [0,1].
This made it possible to compare semantic deviation across tasks, prompts, and contexts using a shared scale.

Key advances in this stage include:

  • Normalization of deviation into a consistent range.
  • Introduction of zones such as safe, transit, risk, and danger.
  • Coupling deviation dynamics with control logic, for example hysteresis and progression guards.

The goal of WFGY 2.0 was operational consistency.

  • Different tasks could be analyzed under the same tension language.
  • Stability decisions no longer depended on ad hoc heuristics.

WFGY 3.0 · Multi observable tension and auditability

WFGY 3.0 extends the previous scalar approach into a structured family of observable deviations written as DeltaS_*.
Instead of forcing all semantic risk into a single number, each task defines explicit, named observables. Examples include reference grounding, outcome stability, and constraint adherence. These are then aggregated under fixed, pre declared rules.

This version emphasizes auditability and robustness.

  • Each DeltaS_* must be explicitly defined, normalized, and locked.
  • Aggregation rules cannot be altered per model or per experiment.
  • Guardrails prevent post hoc adjustment or hidden tuning.

In WFGY 3.0, tension is no longer just a control signal. It becomes a verifiable interface between reasoning behavior and system constraints.

Summary

Across all versions, the core idea remains unchanged.

Semantic failure should be observable, quantifiable, and constrained. It should not be corrected only through weight updates or opaque rewards.

WFGY 3.0 represents a maturation of this idea into a form suitable for reproducible experiments, comparative evaluation, and cross model analysis, while remaining conceptually continuous with earlier versions.

Back to top