Skip to content

Phuire-Research/Stratimux

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Stratimux

The Muxified Turing Machine - The Advent of the Strong Fast Computer in Plain Text, that Solves the "impossible halting problem" of Classic Turing Machines, in the Spirit of the Open Internet

Features:

  • Universal Transformer
  • StratiDECK Interface System (Higher Order Conceptual Composition)
  • ICE - Intelligently Crystallized Executable
  • Function as an Operating System
  • Halting Complete
  • Concept Libraries (Deck)
  • Action Oriented (Smalltalk Cellular Messaging)
  • Single Network Lock (Mutex as Ownership)
  • Asynchronous Graph Framework
  • Composable Strategies (ActionStrategy)
  • Stage Planner (Higher Order Reasoning)
  • Prioritization
  • Change Detection
  • Plain Text Dialog Output
  • Hot Loading
  • No Dependency Injection

Getting Started

What is Muxification?

Muxification is a Multiplex of Quantitative and Qualitative Reasoning. Stratimux represents a Code as Proof of Concept for this new System. Where a Concept in this system is something in the pursuit of being fully measured, rather than nebulous or abstract. That goes a step further than traditional methods, including the ability to demuxify concepts.

Advice when encountering branch prediction errors.

The easiest means of detecting if your application is starting to encounter such errors is to enable the dialog and logging options on your Muxium. To avoid running into these branch prediction errors. Attempt to limit your strategy assembly, qualities, and plans to be less than O(n^3). You will find that your functions will suddenly become probabilistic in their ability execution deterministically.

Thankfully, this is the reason for the atomic behavior of your qualities combined with strategies and plans. As you may shrink time complexity into a series of steps. Or better yet, if you are relying on accessing some parameters from your state. Be sure to flattened those data structures into something that can readily be accessed.

When in doubt simplify.

Concept Index

  • Action Strategy - Data structure that allows for Stratimux to be provably terminating.
  • Muxium - Governing concept that contains the set of concepts that formalizes each muxium.
  • Concept - Concepts are composed of state, qualities, principles, and mode.
  • Stage Planner - Slices your application into different stages and prevents action overflows.
  • Action Controller - Allows methods to be performed asynchronously.
  • Strategy Data - Enables the Action Strategy pattern to perform as a "Universal Transformer."
  • Higher Order Conceptual Composition - Advancing Logical Graph Programming towards the Unlimited Pursuit of Exploring Conceptual Space.
  • Spatial Ownership - A single lock concept that can be within a single process or network of muxiums.

Want to learn more?

Change Log Tests

Stratimux 0.3.22: Stratideck - Complete Architecture

View Full Release Notes

⚠️ BREAKING CHANGES: v0.3.22 introduces major type system changes requiring migration.

📋 Complete Migration Guide →

Summary: Day One of Stratimux - The Design Intent Realized

Core Achievement

v0.3.22 represents Day One of Stratimux - the moment when the framework's architectural vision becomes reality through the Stratideck system.

The Problem Solved

  • Semaphore limitations: All qualities of same type shared identical semaphores limited comparisons to in concept.
  • No concept individualization: playerCounter.add() and sessionCounter.add() were indistinguishable
  • Single origin constraint: Could only have one source per quality type

The Identity Solution

  • Simple function comparators: c.playerScore.add(action) - just a function call
  • Unique identities: Same quality patterns, different identities per concept instance
  • Cross-concept distinction: Multiple counters/timers with individual identities

Higher Order Composition Principle

Proven: All complex concepts are compositions of simpler concepts

  • Reuse concept patterns (Counter, Timer, Toggle) across different muxified concepts
  • Maintain unique identities through the DECK interface system
  • Build sophisticated applications from proven building blocks

The Stratideck Design Intent

  • Concept sharing: Reuse patterns while preserving distinctness
  • Muxified interface: StratiDECK system {d:.. {d:.. {e, c, k} e, c, k}, e, c, k} ease of higher order composition access
  • Type safety: Full inference across concept boundaries
  • Compositional architecture: Complexity through composition, not complication

Architectural Impact

  1. True concept portability with identity preservation
  2. Scalable complexity through proven patterns
  3. Effective mapping - distinguish between same quality types
  4. Foundational completion - enables Stratimux's designed potential

Day One Significance

This release completes the foundational architecture that enables the compositional future Stratimux was designed for - transforming from technical framework to complete architectural paradigm.

Key Features & Changes

🎯 Complete STRATIDECK (Deck of Decks) Interface System

  • No imports needed: Direct access to actions, selectors, and semaphores via deck interface
  • Entry points: d (decks), e (actions), c (comparators), k (selectors)
  • Type safety: Full TypeScript inference throughout the system

🔧 Enhanced Quality-of-Life Features

  • Debug improvements: lastStrategyActionList automatically stored without performance overhead
  • Stage composition: New createStages helper for scoped, readable stage planning
  • Better development experience: Improved error handling and development tooling

⚠️ Breaking Changes - Migration Required

This release introduces a major type system overhaul requiring explicit quality type definitions:

// OLD (breaks at scale)
export type CounterQualities = typeof counterQualities;

// NEW (required for type safety)
export type CounterAdd = Quality<CounterState>;
export type CounterQualities = {
  counterAdd: CounterAdd,
  // ... explicit mapping required
};

📈 Why the Boilerplate Increase?

Even though the abstraction adds more boilerplate, it becomes necessary when a concept acquires enough qualities - TypeScript starts to break down in its typings. This change ensures type safety and reliability at scale.

📊 Impact

  • 91 files changed (+4,189 additions, -969 deletions)
  • All concepts: Require explicit quality type interfaces
  • All tests: Updated for new type patterns

Complete migration details and examples →

Other typescript projects

npm i stratimux@latest

From the template template

npm run start

Project Structure

src/ index.ts
src/ concepts / muX / qualities / qOfMux.quality.ts
     concepts / muX / strategies / muXSome.strategy.ts
     concepts / muX / muX.concept.ts
     concepts / muX / muX.principle.ts
     tests / example.test.ts

muX.concept.ts

Treat your concepts as libraries, modules, and/or(anor) entire applications. As that was the initial inspiration for this system. Beyond this initial release, there will be a growing library of Standardized Concepts for utilization within your Muxiums. Including the ability to finally have an easy means of composing "Web Components," into your system. While enhancing upon their functionality, versus just the drop in.

import { Concept, createConcept, MuxiumDeck, PrincipleFunction, Quality } from 'stratimux';
import { muXqOfMux, MuXqOfMux } from './qualities/qOfMux.quality';
import { muXPrinciple } from './muX.principle';

export type MUXState = {
  message: string
}

export const muXName = 'muX';

export const createMUXState = (): MUXState => {
  return {
    message: 'Hello World!'
  };
};

// v0.3.22 REQUIRED: Explicit quality type mapping for type safety at scale
export type MUXQualities = {
  muXqOfMux: MuXqOfMux;
};

export type MUXDeck = {
  muX: Concept<MUXState, MUXQualities>;
};

export type MUXPrinciple = PrincipleFunction<MUXQualities, MuxiumDeck & MUXDeck, MUXState>;

export const createMuXConcept = () => {
  return createConcept(
    muXName,
    createMUXState(),
    {
      muXqOfMux
    } as MUXQualities,
    [
      muXPrinciple,
    ],
  );
};

muXqOfMux.quality.ts

This isolates all the parts necessary for your actions to have impact within this system. Types are a qualitative description of the overall quality. As even though they are not explicitly used within this system. They likewise better inform training data, and likewise act as unique identifiers if you are accessing the action creators directly versus the DECK System.

Internally Stratimux uses semaphores as the method of quality routing within the Muxium. This is to reduce the time complexity of each look up. To further increase the speed of execution of your applications, utilize the supplied DECK Interfaces at each point of entry.

import {
  createMethodWithState,
  strategySuccess,
  strategyFailed,
  createQualityCardWithPayload,
  strategyData_muxifyData,
  Quality
} from 'stratimux';
import { MUXDeck, MUXState, } from '../muX.concept';

type muXOfMuxPayload = {
  message: string
}

export type uXqOfUxField = {
  state: MUXState
};

function getRandomRange(min: number, max: number) {
  return Math.random() * (max - min) + min;
}

// v0.3.22 REQUIRED: Export explicit quality type for concept type mapping
export type MuXqOfMux = Quality<MUXState, muXOfMuxPayload>;

export const muXqOfMux = createQualityCardWithPayload<MUXState, muXOfMuxPayload, MUXDeck>({
  type: 'muX allows for easy selection of your qualities, muXqOfMux is your quality, and Type is the distinction',
  reducer: (_, action) => {
    const {message} = action.payload;
    return {
      message
    };
  },
  methodCreator: () => createMethodWithState(({action, state}) => {
    if (action.strategy) {
      // P/NP?
      const even = Math.round(getRandomRange(1, 5)) % 2;
      if (even) {
        const strategy = strategySuccess(action.strategy, strategyData_muxifyData(action.strategy, {
          state
        }));
        return strategy;
      } else {
        const strategy = strategyFailed(action.strategy);
        return strategy;
      }
    }
    return action;
  })
});
/* Below are the default functions available for your quality */
// export const qOfUXQuality = createQuality(
//   qOfUXType,
//   defaultReducer,
// The method is optional and is an advanced behavior
//   defaultMethodCreator
// );

muX.principle.ts

Your concept's "main" function. This will be called after the muxium initializes.

import {
  getMuxiumState,
  strategyBegin,
  createStages
} from 'stratimux';
import { muXName, MUXPrinciple } from './muX.concept';
import { muXSomeStrategy, muXSomeStrategyTopic } from './strategies/muXSome.strategy';

export const muXPrinciple: MUXPrinciple = ({
  plan
}) => {
  // There always needs to be atleast one subscriber or plan for the Muxium to be active.
  const muxPlan = plan('muX Plan', ({stageO, stage, d__}) => [
    // This will register this plan to the muxium, this allows for the muxium to close or remove your concept cleanly.
    stageO(() => (d__.muxium.e.muxiumRegisterStagePlanner({conceptName: muXName, stagePlanner: muxPlan}))),
    stage(({concepts, dispatch, k, d}) => {
      const state = k.state(concepts);
      if (state) {
        dispatch(strategyBegin(muXSomeStrategy(d)), {
          iterateStage: true
        });
      }
    }, {beat: 30}),
    stage(({concepts, stagePlanner}) => {
      const {lastStrategy} = getMuxiumState(concepts);
      if (lastStrategy === muXSomeStrategyTopic) {
        stagePlanner.conclude();
      }
    })
  ]);  // v0.3.22 Advanced: Using createStages helper for improved scoped composition
  // *Note* when accessing your deck from outside of Stratimux, you will need to supply your Deck Type Interface to the plan to access such. This is a QoL Decision allowing for Stratimux to be adapted to any number of environments.
  const muxPlanWithStages = plan<MUXDeck>('muX Plan with createStages', ({d__}) => 
    createStages(({stageO, stage}) => {
      // By using createStages you gain access to scope encapsulation while maintaining type safety. 
      // This allows you to process which stages you would like to include in an open environment, 
      // versus having to perform sophisticated one-liners and reducing readability.
      const stageRegister = stageO(() => (d__.muxium.e.muxiumRegisterStagePlanner({conceptName: muXName, stagePlanner: muxPlanWithStages})));

      const stageDispatch = stage(({concepts, dispatch, k, d}) => {
          const state = k.state(concepts);
          if (state) {
            dispatch(strategyBegin(muXSomeStrategy(d)), {
              iterateStage: true
            });
          }
        }, {beat: 30});

      const stageFinalize = stage(({concepts, stagePlanner}) => {
        const {lastStrategy} = getMuxiumState(concepts);
        if (lastStrategy === muXSomeStrategyTopic) {
          stagePlanner.conclude();
        }
      });

      return [stageRegister, stageDispatch, stageFinalize];
    })
  );
};

muXSome.strategy.ts

When you are creating your strategies within this system of design. You are optimizing towards success, and majority of your strategies should be taking place within that mind set. Failure is just a chance to get back on track and see the end of some strategy, but likewise you have to account for that failure ahead of time.

This approach to algorithm design is the core strength of Stratimux, but likewise its weakness due to branch prediction. Therefore be mindful if your strategies behave in unexpected ways. The Stage Planner paradigm, especially the beat attribute should be your first go to. As chances are your logic is becoming to complex and you need to tone down when parts of your application are notified changes to state.

import { ActionStrategy, createActionNode, createStrategy, Deck, MuxiumDeck } from 'stratimux';
import { MUXDeck } from '../muX.concept';

export const muXSomeStrategyTopic = 'muX Some Error Correcting Strategy';
export const muXSomeStrategy = (d: Deck<MuxiumDeck & MUXDeck>): ActionStrategy => {
  const stepSuccess = createActionNode(d.muxium.e.muxiumLog());
  const stepFailure = createActionNode(d.muxium.e.muxiumKick(), {
    successNode: stepSuccess,
  });
  const stepBegin = createActionNode(d.muX.e.muXqOfMux({
    message: 'Muxification Hello World'
  }), {
    successNode: stepSuccess,
    failureNode: stepFailure
  });
  return createStrategy({
    topic: muXSomeStrategyTopic,
    initialNode: stepBegin
  });
};

index.ts

Notice that beyond creating the muxium, there is no need for additional input. As the muxium is a recursive function. Your concepts are initialized internally via the principle that you have assigned to your concept. Note that you may still subscribe, stage, and dispatch actions into an muxium.

import { muxification } from 'stratimux';
import { createMuXConcept } from './concepts/muX/muX.concept';

(() => {
  const muxiumName = 'Your Muxium';
  // Sets logging to true and store dialog to true
  //  This will log to the console the dialog of each successive ActionStrategy
  //  And store the entire application context in the muxium's dialog.
  muxification(muxiumName, {muX: createMuXConcept()}, {logging: true, storeDialog: true});
})();