Infographic 1 Infographic 2 Infographic 3 Infographic 4

Presentation Notes: Workflow Mechanisms

Architects of Intent

Architectural mechanisms for work with explicit limits, inspectable evidence, finite outcomes, and separate admission.

Three Explicit Surfaces (Map · Terrain · Ledger)

A loop becomes governable when three things are explicit: what is declared for the property, what actually runs, and what evidence justifies each transition.

MAP
Versioned description
A versioned representation of intent or observed structure, authoritative only for declared properties.
TERRAIN
What actually runs
The source, configuration, behavior, and external state the workflow can observe or affect.
LEDGER
Reconstructable evidence
Intent, input fingerprints, effects, structured results, and transitions. Under protected-sink and trust-root assumptions, missing or contradictory required evidence fails closed.
Example project tree








File


—











read
write
execute
Toggle trace to see what the loop reads, writes, and runs.




















Intent becomes proposed authority before it becomes active


From Request to Activated Mission


AI may help draft the work contract. A protected binding step resolves its material references, final review evaluates that exact proposal, and separate authority activates its content-addressed identity.







1. Human request

“Preserve the released API while adding pagination metadata.”






2. Draft Mission Object

A proposed objective, authority, effects, outputs, checks, budgets, routes, and output-appropriate handoff.






3. Bind and review

Resolve material references to immutable identities, then evaluate the fully bound proposal against intent and policy.






4. Separate Activation

An authorized identity or adopted policy authorizes that exact content-addressed Mission identity.









Mission Object: instruction

    

  • Fixed during the run
    • 

  • Fully bound before Activation
    • 

  • States what may happen
    • 






Run Record: history

    

  • Records attempts, observations, and effects
    • 

  • Retains findings and transitions
    • 

  • Seals at every terminal result
    • 







The inverse path is also proposal-only: admitted implementation and runtime evidence may support a human-readable Map update, but observation cannot install intent.













One probabilistic invocation


The Deterministic Sandwich


Deterministic preparation constructs the request. One probabilistic step proposes a candidate within named limits. Validation outside candidate authority parses and checks the result.







1. Prepare

Read the activated work contract, select a bounded Context Packet, and construct the required input shape.






2. Propose

A model, agent, harness, CLI, service, or child workflow returns one candidate output.






3. Validate

Parse strictly, check the Mission's properties and effects, and emit structured findings.









Stable across attempts

Intent, authority, input contract, output schema, checks, budgets, and stopping rules.





Allowed to vary

The candidate produced by the probabilistic step and the findings returned about it.






A Validator result is evidence for routing. It is not Admission or Adoption, and a retry policy belongs to the enclosing workflow.
















Skeleton-First: Scaffold or Extract



        A skeleton can prescribe the minimum structure implementation must preserve, or describe exact structure observed in Terrain. Authority direction determines which one it is.
      




one technique · opposite authority direction








1 · Map to Terrain


Prescriptive minimum viable scaffold



        Adopted structure comes first. Implementation may fill content and expand only the points the Map declares.
      




Fixed root


Architecture guide


Top level · dashed = declared expansion



Problem
Mechanism — declared expansion point
Limits



Mechanism expands to



Inputs
Transformation — declared expansion point
Outputs



Transformation expands to



Preconditions
State changes
Postconditions






Possible formalization:
        when a stable grammar recurs, outline to schema to domain-specific language. Each transition requires separate adoption.




Content topology:
        declared expansion points below downward · derivable parent views above upward







2 · Terrain to Map


Descriptive extracted skeleton



        Terrain-to-Map work records exact observed structure first. It preserves provenance and leaves judgment-heavy prose as a proposal.
      






Routes


GET /orders
POST /orders


routes.py@8ac4e1






Commands


CreateOrder
CancelOrder


commands.py@8ac4e1






Ownership


orders/**
owned by commerce-team


CODEOWNERS@8ac4e1







        Terrain to exact upward inventory + aggregation to Map
      






Normalized Terrain inventory


2 routes · 2 commands · 1 ownership rule




content-addressed observation · source revision 8ac4e1 · no inferred rationale






Compare, then propose



          The updater compares this observation with the selected Map surface. Any change to that surface, rationale, or judgment-heavy prose remains a proposal until separately reviewed and adopted.
        










Content structure says what is nested.


Context Graph makes source identities and typed relationships addressable; policy selects the slice.


Governed Workflow controls allowed transformations, checks, and effects. The three topologies need not match.















Checks selected before the run


A Validator Suite Produces Partial Evidence


The activated work contract selects the required checks. Each check settles only the property it was designed and authorized to evaluate.







Structure and syntax

    

  • Parser or JSON Schema
    • 

  • Formatter or linter
    • 

  • Type checker
    • 






Behavior and correspondence

    

  • Unit or contract test
    • 

  • Released-interface comparison
    • 

  • Protected policy check
    • 











Candidate

The proposed state and its declared effects.






Structured findings

Pass, fail, inconclusive, or a recorded reason the check could not run.






Declared routing

The Judge consumes findings; it cannot invent them or reinterpret failure as success.






For a consequential property, a model-based evaluator is not the sole oracle unless adopted policy accepts the measured error of that exact protocol.













Finite adaptation without changing authority


The Bounded Refinement Loop


Findings may guide another proposal. They do not change the Mission, grant new effects, or remove the stopping rules.







1. Propose

Produce one candidate from the activated work contract and current working state.






2. Check

Run the required checks and retain normalized findings, omissions, and attempted effects.






3. Decide

Select one transition permitted by the Mission from the findings and remaining budgets.






4. Refine or seal

Use specific findings for another attempt within budget, or reach one terminal result and seal the Run Record.









complete

The run met its completion conditions. A change candidate is now a supported proposal; Admission or Adoption remains separate.





no_change

The required property already held and no candidate effect exists.





blocked

The Run Record names the external authority decision, trustworthy-oracle restoration, or environment repair needed for a new linked run.





failed

A breaker or failure condition ended execution, and no named external action can resolve it.









Working state

Latest candidate, comparable findings, completed checks, recent normalized states, and remaining budgets.





Reconstruction evidence

The logically append-only account of each attempt, effect, finding, and transition, retained outside candidate authority.


















Protected non-regression


Validate, Then Commit Admission and Floor Together


Validation may support proposal closure against one protected floor revision. Current-state Admission commits the candidate and next floor as one transaction.







Protected state

Protocol: code-health@7
Floor: revision 42
Worker access to floor: read-only





Invariant

For this candidate, failure, uncertainty, stale state, or a transaction write failure commits neither Admission nor floor advancement. Lowering the floor requires a separate Governance Mission and separate Adoption.






Candidate scenario










One lint finding is removed while required behavior remains unchanged and the current floor is preserved.




1. Measure


2. Judge


3. Seal


4. Admit + CAS floor







Protected check

not run





Terminal result

not run





Admission + floor

not eligible





Accepted floor

revision 42













The candidate has not been evaluated.

















Maintenance Controller: Scan, Select, Dispatch



              A maintenance scan produces a checked report and seals its Run Record. Only a separately activated
              Mission may produce a supported proposal; proposal closure never implies Admission.
            








3









Required Sensor





Top target





Child activation





Child Validators























Scan


Pin + Sense






Select


Qualify + Rank






Close scan


Report + Judge






Boundary


Activate Mission






Child run


Act + Verify












Maintenance scan record


OPEN





Status
ready
Evaluated
0/3
Selected
none
outputs.checked
false



ledger/maintenance/scans/scan-00.json








Maintenance Mission record


NOT ACTIVATED





Status
not_activated
Candidate
none
outputs.checked
false
Admission
not_applicable



ledger/maintenance/missions/not-activated








Declared evidence frontier




Manifest + Terrain pinnedPENDING


Eligibility recordedPENDING


Report output checkedPENDING


Child Mission activatedPENDING


Validator frontier completePENDING


Proposal output checkedPENDING







              No child Mission is activated. Scan authority and child-Mission authority remain separate.
            




















Sensor Hierarchy (UML-Style)



        Treat Sensor as a base interface, then specialize by terrain surface. Different sensors emit
        different signal shapes, cadences, and confidence profiles.
      




Base contract



class Sensor
+ read(): Signal
+ descriptor(): SensorDescriptor
+ mode: READ_ONLY
Judge consumes the emitted signal; Effectors own mutation.











Interactive model




Base Class


Sensor


read() | descriptor() | mode=READ_ONLY

























Environment volatility
34/100









Sensor bundle



























Active sensors


2






Coverage


0%






Blind spots


0






Signal confidence


0/100








Selected sensor descriptor




Emitted bundle signal




Select a class and emit a bundle signal.








Event stream


Blue = emit, red = denied write

























Governance: Findings, Judgment, Admission



      Validators outside candidate authority emit complete findings. The Judge selects an allowed transition, and the runtime
      seals the Run Record. The Mission Gate separately revalidates a supported proposal before Admission.
    








Protected chain


    

  1. 

    1. Bind authority
    

    Mission, base, candidate, policy/data bundle, evaluator, and declared effects are content-addressed.
    

    2. 

  2. 

    2. Emit findings
    

    Required Validators return pass, fail, or inconclusive. Every result remains visible.
    

    3. 

  3. 

    3. Seal the Run Record
    

    Required output checks complete the evidence frontier before the Judge chooses an allowed transition and the runtime seals the Run Record.
    

    4. 

  4. 

    4. Revalidate for Admission
    

    The Mission Gate revalidates current bindings, approvals, exception scope, and kill state.
    

    5. 





deny-overrides


Priority may route notification or repair. It never erases another required failure.






human boundary


Humans adopt policy and authorize exact exceptions. They do not manufacture passing evidence.








Choose a case

























Policy bundle


READY






Validators


NOT RUN






Judge result


PENDING






Admission


NOT CHECKED










Complete findings




No exception artifact.








Ledger events


run 0