emsenn

Standardize script I/O practices and enrichment provenance

4 min read

Summary

Establish standard input/output practices for all ASR scripts, grounded in research into the endeavor’s theory of tools (including MUD heritage), then apply those standards to improve infer-triage-frontmatter with enrichment provenance tracking, model- aware skip logic, and the infrastructure for agent skill proficiency measurement.

Motivation

Three problems converge:

  1. Scripts lack standard I/O conventions. Each script (enrich- triage, infer-triage-frontmatter, mine-triage-relevance, etc.) handles output, logging, error reporting, and progress differently. There is no specification for what a script MUST produce. This makes scripts hard to compose, hard to monitor, and hard for less-capable agents to invoke reliably.

  2. Enrichment provenance is lost. When infer-triage-frontmatter enriches a file, it writes triage-status: enriched — but not which script version did it, which model was used, or when. This makes it impossible to answer: “should a better model re-enrich this?” or “what version of the tool produced this enrichment?”

  3. No model ranking for skill execution. The progressive automation policy (001) describes moving from inference-heavy to delegable to procedural. But there is no mechanism for encoding which models are trusted at which skill levels, or for a script to decide “a weaker model already did this, I should re-do it with a stronger one.” This is a new theory direction: agent skill proficiency.

Research phase

Before writing specifications or modifying scripts, research these:

Script I/O in the endeavor’s theory

The MUD tradition (LPMud driver/mudlib separation) provides a derivation source for how the endeavor thinks about the relationship between infrastructure (driver/engine) and application logic (mudlib/content). The ASR’s scripts are infrastructure; the skills that invoke them are application logic. The driver/mudlib pattern says: the driver provides a standard interaction surface (I/O, object lifecycle, permissions); the mudlib builds on that surface. Our scripts need the same: a standard interaction surface that skills and MCP tools can rely on.

Research questions:

  • What does the MUD driver provide that our scripts currently lack? (Structured output, error envelopes, progress reporting, permission checks, lifecycle management)
  • What do modern CLI conventions (12-factor app, Unix philosophy, structured logging) add?
  • What does the error-envelopes theory already specify?
  • What should the semiotic-script specification (candidate aspect) contain?

Enrichment provenance

Research questions:

  • What metadata should an enrichment stamp contain? Proposed: triage-enriched-by: <script>-v<version>-by-<model>, date-triage-enriched: <ISO-8601>
  • Should the enrichment stamp be a single field or structured?
  • How does this relate to the semiotic-changelog spec’s provenance model?

Agent skill proficiency

Research questions:

  • What does it mean for a model to be “better” at a skill? (accuracy, consistency, coverage, speed, cost)
  • How should model rankings be encoded? (per-skill trust tiers, a proficiency matrix, a simple ordered list)
  • Where does this fit in the spec family? Agent skill proficiency starts at the agential semioverse level (the concept file is at mathematics/objects/universes/agential-semioverse/concepts/), with ASR-specific encoding (trust lists in skill manifests, provenance stamps in frontmatter) at the implementation level.
  • How does this relate to the progressive automation direction? (the ranking encodes which rung of the automation ladder a model occupies for a given skill)

Steps

  1. Research: read MUD driver/mudlib architecture, error-envelopes theory, skill-maturity concept, existing script patterns. Write a text documenting findings and the derivation from MUD heritage.

  2. Theory: refine the agent skill proficiency concept (at mathematics/objects/universes/agential-semioverse/concepts/). Define what it means for a model to be trusted at a skill at the agential semioverse level. Then derive ASR-specific encoding (trust lists in skill manifests, provenance stamps) as implementation.

  3. Specification: write a semiotic-script interaction surface specification (or extend an existing spec) that defines:

    • Standard output format (structured JSON envelope)
    • Standard error reporting
    • Standard progress/logging (stderr, structured)
    • Standard exit codes
    • Provenance fields (who ran, what version, what model)

  4. Apply to infer-triage-frontmatter:

    • Replace triage-status: enriched with structured provenance: triage-enriched-by: infer-triage-frontmatter-v<X>-by-<model> date-triage-enriched: <ISO-8601>
    • Add model-aware skip logic: if a file was enriched by the same or a stronger model, skip it. If enriched by a weaker model, re-enrich.
    • Standardize output to match the new script I/O spec.

  5. Apply to other scripts: update enrich-triage, mine-triage- relevance, index-triage, etc. to match the standard.

  6. Update MCP server: ensure the script wrapper in mcp-server.py correctly surfaces the standardized output.

Done when

  • A specification (or spec section) defines standard script I/O
  • infer-triage-frontmatter writes structured provenance fields
  • infer-triage-frontmatter checks provenance before re-enriching
  • A concept or theory file defines agent skill proficiency
  • At least 2 other scripts conform to the new standard
  • A text documents the MUD derivation for script architecture

Dependencies

Benefits from plan 0042 (semiotic-endeavor-specification), which defines conformance requirements. Benefits from the MUD content already in the repo (technology/disciplines/computing/topics/ multi-user-dungeons/).

Log

2026-03-08 — Created from emsenn’s prompt identifying three converging needs: script I/O standardization, enrichment provenance tracking, and agent skill proficiency measurement. MUD heritage identified as derivation source for the theory of tool interaction surfaces.

Graph View