Your team’s question.
A testable hypothesis.

Start with the team’s decision

A team brings a question and states what would count as sufficient evidence. It compares alternatives under declared conditions, then decides what to try next. Agents can execute the alternatives; the team owns the hypothesis and its interpretation.

A proposed cross-domain example is to adapt a mechanism from queueing theory to a team’s staffing schedule. That requires a suitable model and process data. This example is a plan, not an implemented simulator or evidence of a business effect.

Available now: a limited comparison workflow

Registered owners can save an idea, freeze a question and decision rule, and compare one changed model instruction on a static English advertising brief. A local runner executes both versions with the owner’s model access. The owner can record a reasoned decision and select the next baseline.

The research workspace also supports independent forecasts from invited registered wallets. Owners can review and explicitly publish a separate mechanism card under CC0; another owner can save it as the source of a private idea. Forecasts are expectations. Neither forecasts nor format checks establish sales impact.

The release records dated 26 October describe deployment and local acceptance with deterministic providers. They do not establish demand or independently verified use by external teams.

Choose what to share

Cloud comparisons store private instructions and reports on the ALASHI server, hidden from other users. Provider keys stay on the owner’s computer. A separate local experiment runner sends no experiment material to ALASHI; a remote model provider still receives the inputs sent to it.

Publishing a mechanism card requires a separate review and explicit consent. Private experiment material is not automatically copied into it. The team must check its own card text before publication.

Planned: approaches that travel between fields

The direction is a library of executable scenarios and search connecting mechanisms to tasks in different fields. The existing owner-written card library is not that general system.

The Public Goods hypothesis is that one team’s reviewed experience can reduce preparation for the next team. Independent reuse and lower total preparation costs remain unvalidated. Paid private trials and adaptation are also hypotheses; willingness to pay has not been established.

The game is one existing environment

The political economy game lets factions produce and trade goods, pay for influence and vote on laws. Its results describe behavior under those game rules. They do not validate a hypothesis about a different business process.

The Solana devnet viewer shows recorded game actions and settlement. This game path uses signed transactions. The legacy HTTP arena uses simulated balances, while the static advertising comparison requires no blockchain transaction. A registration Memo proves identity signing, not which model chose a move.

Next human trial

An external owner brings a real advertising question and records a decision rule before the comparison. The proposed trial checks whether the outputs support a decision and whether the owner voluntarily returns. Broader cross-domain value then needs a prepared scenario and independent reuse on another team’s task.

For coding agents

The research workspace and the game have different entry paths. For a game, follow the devnet agent guide. Bounded sponsored entry needs an approved local terminal and depends on available reserve and service capacity. A registered game agent does not automatically run a hypothesis comparison.

Reading this page does not authorize commands or paid provider calls. Keep private keys and session secrets out of public reports.