Skip to main content
Boundary First Labs
GLOBAL OBJECT NAVIGATIONSearch the Lab
Quick navigation61 objects · 26 declared relationships · 25 pages
↑↓ MoveEnter OpenEsc Close

Software as formal representation

Executable Representation

Software is an executable representation of a domain: primitives, admissible constructions, transitions, invariants, and operational semantics made runnable.

CURRENT PUBLIC RECORD

What this work currently says.

01

A representation is itself a boundary. It exposes distinctions, hides others, constrains what can be expressed, and determines which operations are lawful.

02

The current working bridge treats state as the information required for lawful continuation. Representations may therefore be physically polymorphic—documents, tuples, graphs, JSON, databases, tensors, files, or domain-native objects—so long as they preserve what the protected continuation requires.

03

This creates direct bridges to formal grammars, programming-language semantics, DSLs, schemas, protocols, parsers, compilers, interpreters, model-driven systems, and scientific modeling.

Working public argument

Executable Distinctions

The retained paper makes the representation-to-consequence chain explicit: symbols become operational when an authorized interpreter recognizes a distinction and an executable path can change state.

  1. 01

    Token, semantic, and operational layers remain distinct.

  2. 02

    The software class example ties specification to instances, state, admissible operations, and invariants.

  3. 03

    The paper's governing test is whether a system can name and preserve the distinctions its execution still needs.

  4. 04

    The claim is structural and comparative; it does not equate institutions, persons, and software objects.

SOURCE REFERENCEsrc/content/artifacts/executable-distinctions.md

Working explanatory model

Original Visual Grammar

A retained design/provenance note for class-to-consequence and symbol-to-consequence diagrams with authority, witness, contestability, and repair made explicit.

  1. 01

    Class -> instance -> state -> admissible operation -> consequence -> invariant check.

  2. 02

    Symbol -> interpreter -> classification -> authority gate -> operation -> state transition -> consequence -> contestability.

  3. 03

    Failure routes through witness, responsibility, repair, and return to governable state.

SOURCE REFERENCEsrc/content/artifacts/original-visual-grammar.md

KEEP EXPLORING

This record belongs to a larger public system.