{
  "name": "MEKreflect",
  "updated": "2026-10-16",
  "scope": "Public development notes. Curated summaries, not private source archives.",
  "research": [
    {
      "slug": "context-handoffs",
      "title": "Context and handoffs",
      "category": "Operational AI research",
      "status": "Implemented workflows and recorded experiments",
      "summary": "Useful AI work depends on what the next person or digital worker receives. This research examines source versions, specialist responsibilities and the uncertainty that can disappear when work moves between roles.",
      "question": "How can a handoff preserve the evidence, unresolved questions and decision context needed to carry work forward?",
      "method": [
        "Start with an operational process and identify the sources, responsibilities and decisions at each stage. Give specialist workers distinct review questions, a shared source context and an explicit output contract. Reconcile their available findings rather than assuming every branch succeeds.",
        "Use fictional source packs to compare fuller and deliberately incomplete receiving contexts. Retain the actual worker outputs, inspect the structured fields separately from the prose, and replay deterministic source checks without rewriting the original response."
      ],
      "findings": [
        "A recorded hosted-AI experiment exposed a mismatch between cautious prose and actionable fields: a worker warned that updates were missing but returned an older deadline and budget ceiling in fields labelled current. The source-manifest correction cleared unsupported current fields in the downstream projection while preserving the received values and raw response.",
        "Source retrieval can resolve missing facts without resolving the whole decision. In more complex development cases, workers disagreed about whether updated sources and approved scalar values also established that finished documents had been reconciled. That disagreement remains part of the result."
      ],
      "limits": [
        "The recorded experiments use authored fictional cases, including a deliberately incomplete context condition. Source coverage does not prove correct interpretation, and matching a local integrity record is not independent authentication."
      ],
      "next": [
        "Develop independently reviewed cases and separate source availability, field currentness and finished-package readiness in the scoring. Compare useful completion and reviewer effort alongside unsupported decisions."
      ],
      "technical": [
        "Role-based context contracts",
        "Parallel specialist review",
        "Partial-failure synthesis",
        "Source-version manifests",
        "Field-level currentness and replay"
      ]
    },
    {
      "slug": "evidence-decisions",
      "title": "Evidence and decision rights",
      "category": "Evidence-governed workflows",
      "status": "Implemented control patterns",
      "summary": "Preparing work, approving it, attempting an action and confirming its completion are different events. This research asks how software can preserve those distinctions and keep human responsibility visible.",
      "question": "What evidence and authority should be required before a workflow advances to its next state?",
      "method": [
        "Connect factual statements to source identifiers and approved wording. Keep unresolved or conflicting material separate from information permitted for a particular output. Treat retrieval as the selection of useful evidence, not a guarantee that a generated conclusion is correct.",
        "Bind completion records to the same case and its registered receipt. Recheck artifact existence, validation status and a stored digest at the state transition. Keep approval decisions separate from the executor that must enforce them."
      ],
      "findings": [
        "Inspected completion controls reject missing, changed or wrong-case receipts. A saved local test run exercised selected identity and tamper checks with temporary artifacts and in-memory state. This makes an attempted action distinguishable from a result supported by an intact record.",
        "Append-only approval records make intent and decisions inspectable, but do not themselves execute approved work. Likewise, a matching artifact digest establishes identity and consistency rather than the semantic truth of the underlying evidence."
      ],
      "limits": [
        "A tested state-transition guard covers its inspected path. Correct evidence curation, authenticated authority and enforcement by every relevant executor remain separate responsibilities."
      ],
      "next": [
        "Test stale approvals, payload changes, repeat attempts and unknown outcomes across one complete bounded workflow. Make the reason for each transition understandable to the person reviewing the work."
      ],
      "technical": [
        "Claim-level provenance",
        "Approved output contracts",
        "Identity-bound completion receipts",
        "Artifact integrity checks",
        "Separate policy, approval and execution"
      ]
    },
    {
      "slug": "operational-integrity",
      "title": "Operational systems and data integrity",
      "category": "Practical systems research",
      "status": "Implemented transactional mechanisms",
      "summary": "Operational errors often begin with ordinary details: an ambiguous unit, a duplicated document, an overlapping reporting period or a stock figure without a physical count. Reliable systems need to preserve those meanings, not merely display convincing totals.",
      "question": "How can a working system remain useful when source records are incomplete, repeated or uncertain?",
      "method": [
        "Represent quantities as exact decimals and monetary amounts as integer minor units. Bind each event identifier to its kind and canonical payload. Return the previous result for an identical retry and reject the same identifier when its details change.",
        "Use transactions for receipt posting and paired transfers so a failure cannot leave half an operation committed. Preserve human-entered events across imports and block unresolved units from creating stock movements.",
        "Keep historical purchases separate from present stock, and observation time separate from the period being reported. Record failed collection, stale coverage and unknown amounts explicitly rather than silently treating them as zero."
      ],
      "findings": [
        "Implemented ledger mechanisms preserve unknown stock until a physical count establishes a baseline. Duplicate receipt controls, payload-bound retries and rollback tests address different ways quantities or money could be counted twice.",
        "The meaning of a record still matters after the arithmetic is correct. Recording a payment allocation does not move money or independently reconcile a bank account. An atomic transfer record does not prove physical arrival."
      ],
      "limits": [
        "The implementation supports bounded local operations, not every accounting or inventory process. Partial deliveries, in-transit stock and auditable reversals require their own workflows and acceptance checks."
      ],
      "next": [
        "Use synthetic records to exercise ambiguous units, retries, late events and partial failures. Develop correction and reconciliation procedures before expanding automation, with a clear owner for each unresolved record."
      ],
      "technical": [
        "Exact quantities and money",
        "Canonical event payloads",
        "Idempotent retries",
        "Atomic commit and rollback",
        "Physical baselines and source coverage"
      ]
    },
    {
      "slug": "model-evaluation",
      "title": "Model evaluation and bounded use",
      "category": "Applied model research",
      "status": "Interfaces, adaptation and numerical experiments",
      "summary": "A model earns a place in a workflow through the task it can perform and the conditions under which it fails. This research connects model interfaces, context limits, local adaptation and computational experiments to practical decisions.",
      "question": "How do a model, its information and its assumptions change a result—and when is that result useful enough to rely on?",
      "method": [
        "Separate provider selection from the actual request. Build explicit failure responses for absent configuration, empty output and transport errors. Inspect which context enters the request and distinguish a conversation-turn limit from a hard token budget.",
        "Keep contextual configuration separate from parameter adaptation. Historical small-model work includes low-rank adapters, dataset revisions, training checkpoints, saved weights and local-inference packaging. Review those artifacts before drawing conclusions about capability.",
        "Evaluate the task and output contract, not only whether a request completed. Compare a base model and an adapted model under common conditions, with source rights, held-out examples and a defensible grader.",
        "Use controlled numerical experiments to examine how information choices and model assumptions alter generated outcomes. Keep input versions, fitted parameters, random seeds and replay evidence visible."
      ],
      "findings": [
        "Provider and routing checks can establish deterministic selection and failure behaviour without establishing current live-provider quality. Budget-aware routing is also different from hard spend enforcement.",
        "Preserved adapter artifacts support a concrete history of parameter-efficient training experiments. Completed training schedules and recorded loss do not establish held-out improvement. Evaluation results from a different external model cannot be attributed to a local adapter.",
        "Repeated-seed numerical work showed differing sensitivity across generated outcomes. That observation concerns conditional simulation, not measured institutional behaviour or a validated forecast."
      ],
      "limits": [
        "The inspected adaptation evidence does not establish production suitability or a reproducible quality gain. In the numerical comparisons, fitted parameters and input information both differed, so the effect of additional information was not causally isolated."
      ],
      "next": [
        "Freeze a permitted held-out task set, inspect the grader and report error, abstention, format validity, latency and resource use. Compare model assistance with deterministic rules and human review where they are credible alternatives.",
        "Investigate information and collective decisions with clearer sensitivity protocols. Hold parameters and source versions constant when isolating an input change, and distinguish reproducible simulated behaviour from external validity."
      ],
      "technical": [
        "Provider abstraction",
        "Context limits and budget signals",
        "Parameter-efficient low-rank adaptation",
        "Baseline and held-out evaluation",
        "Numerical sensitivity and replay"
      ]
    },
    {
      "slug": "people-methods",
      "title": "People and working methods",
      "category": "Practical AI enablement",
      "status": "Individual coaching and a proposed pilot approach",
      "summary": "Developing an AI workflow also means developing the person responsible for it. The working method should help someone brief the assistant, choose appropriate evidence, challenge an answer and decide what happens next.",
      "question": "How can operational knowledge become a repeatable AI working method that people understand and can improve?",
      "method": [
        "Start with the responsibilities a person wants to carry, the inputs the assignment needs and the decisions that remain theirs. Separate essential information from useful background, and facts from assumptions.",
        "Turn that brief into role-based procedures, review questions and useful artifacts. Feedback should improve the next context, instruction or implementation rather than disappear into a conversation.",
        "Design the next stage around one bounded assignment with an agreed owner, approved material and a baseline. Combine practical coaching with a working system so the person can explain and question the result."
      ],
      "findings": [
        "In an individual coaching case, a consultant independently tried the context-first framework on a hypothetical assignment and identified the distinction between essential inputs and helpful background as useful. A follow-up operating plan and assistant instructions were delivered.",
        "That initial trial supports further investigation of the method beyond founder use. The proposed next stage connected a working archive, role-based procedures, reporting and delivery artifacts to a supervised real-work pilot."
      ],
      "limits": [
        "The completed case concerns an individual and a hypothetical exercise. Organisational pilot adoption, measured learning gains and productivity improvement have not been established by that feedback."
      ],
      "next": [
        "Agree a real assignment and review responsibilities before the pilot. Track preparation time, corrections, accepted output and review effort, and ask whether the person can explain the evidence and limitations without relying on the assistant."
      ],
      "technical": [
        "Context-first briefing",
        "Essential inputs and background",
        "Role-based operating procedures",
        "Artifact-based handoffs",
        "Baseline-to-pilot learning"
      ]
    }
  ]
}