Simonson, Andrew 8118a62242 Add Flask web UI, Docker Compose, core engine + tests
- physcom core: CLI, 5-pass pipeline, SQLite repo, 37 tests
- physcom_web: Flask app with HTMX for entity/domain/pipeline/results CRUD
- Docker Compose: web + cli services sharing a named volume for the DB
- Clean up local settings to use wildcard permissions

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-18 13:59:53 -06:00
2026-02-18 11:13:08 -06:00
2026-02-18 11:13:08 -06:00

Applied Combinatorics

Innovation via Attribute Mixing

This is an experimental repo which uses lists of physical attributes and recombines them to form new objects. These objects are then reviewed for comprehensibility and viability.

Example:

Let's identify some methods of getting from here to there:

  • Car
  • Airplane
  • Train
  • Bicycle
  • Walking with your legs
  • Wheelchair
  • Scooter
  • Spaceship
  • Teleportation or beaming technology

To build object 'car' you must select a power source. Power sources include:

  • Gas/Internal Combustion Engine
  • Lithium Ion Batteries
  • Hydrogen Combustion Engine
  • Human pedalling
  • Modular Nuclear Reactor
  • Coal/steam locomotion
  • the Sun via Solar Sail
  • Cannonfire Recoil
  • Pushed by a friend

Putting together lists 1 and 2 we can create 81 mostly novel forms of transportation, such as trains powered by solar sails or walking powered by tiny cannon recoil. Obviously some of these concepts are not as viable as others. While being pushed by a friend might work for those in a wheelchair, it is too slow for those in a car. Speed is therefore a target metric. Let's list some target metrics:

  • Speed
  • Cost efficiency
  • Availability
  • Safety
  • Range (by fuel)
  • Range (by platform degredation or maintenance)

Using these metrics this experiment intends to sift vaguely reasonable concepts from nonsense. Its shortlist may include concepts that sound bizarre but may be technically plausible. Bicycles, motorcycles, and e-bikes all had their turn. Why not hydrogen-bikes?

a few notes: the thin atmosphere and the sun are obvious dependencies to the solar sail power source. Dependencies would include things such as scale of force (nuclear reactor vs pedalling obviously has an important force differential) and geographic requirements (walking requires ground and gravity). The project should include on every entity a list of dependencies. The viability tester will need to pull in all of these dependencies to ensure they do not contradict.

Additionally, metrics are expected to be extremely close to full points or none at all. The speed of a person pushing a car is effectively zero in its domain whereas a rocket powered car would easily reach the limits of speed in the domain. The resulting multiplication between metrics to get the viability score will be heavily logarithmic. This is expected and is intended to be a filter to eliminate technically plausible but completely pointless in practice concepts. Metric weights are therefore dependent on domain, which will also need to be defined.

First pass viability is physics such as force output, possibly generalized by LLM, last passes can include LLM and human review of social factors.

Attributes themselves are real (quality proven) and are thusly not garbage in the 'garbage in garbage out' risk - that risk is measured in how much nonsense the dimensional explosion generates that makes it past heuristic filters.

Description
No description provided
Readme 201 KiB
Languages
Python 78.7%
HTML 16.1%
CSS 5.1%
Dockerfile 0.1%