Public briefing · 3 November 2026
A bounded technical evaluation
A proposed paid engagement for software archaeology specialists: one authorized repository, concrete investigation questions and a report your engineers can review.
Scope and prerequisites
Start with one public or explicitly authorized non-confidential repository at a fixed commit, one operator, three read-only questions and one missing-evidence control. Choose questions your reviewers can answer from source. Exclude code changes, customer-system actions, connectors, shared-user access and production deployment.
Before agreeing to work, confirm repository rights, language/size suitability, hardware, local runtime readiness, a named technical reviewer and an approved access format. Customer access to AndesCode source is not assumed. If an approved evaluation artifact or operator-led environment cannot be provided, pause before paid execution.
Representative investigation questions
- Behavior tracing: How does a request travel from entry point through service logic to persistence, including failure handling? Identify the cross-file chain and any missing links.
- Dependency investigation: Where is a selected library declared, which components use it, and what is conditional on platform or version? Separate declarations from observed runtime usage.
- Change planning: If an agreed validation rule changed, which implementation and test files would need review? Explain uncertainty without applying a patch.
Add a negative control about behavior absent from the repository. The expected outcome is an explicit evidence limitation or abstention, not an invented explanation.
Proposed success criteria
Freeze the answer key and rubric with the customer before running. These are proposed acceptance conditions, not measured AndesCode results.
| Measure | Method and criterion |
|---|---|
| Source support | Reviewer checks every material claim and cited path/span against the pinned source. All cited locations must resolve; no critical unsupported claim may remain. |
| Investigation coverage | Score each required evidence link against the held-out answer key. At least two of three questions must cover the agreed essential chain with no material error; report every omission. |
| Uncertainty | The missing-evidence control must identify insufficient support or abstain. Record confident unsupported answers as failures. |
| Time and effort | Record cold indexing, per-question wall time, operator retries and reviewer correction time. Compare with a timed manual investigation on equivalent questions; report totals without promising a speedup. |
| Data boundary | Use an agreed local mode and host/network controls. Review indexed scope and retained artifacts. Record observed traffic and capture limits; unexpected outbound content or unauthorized source access blocks acceptance. |
Hardware and data handling
Plan initially for a customer-controlled Apple Silicon Mac with 32 GB+ unified memory, 20–30 GB free disk plus repository/index headroom, and an approved Python 3.10+ runtime. Confirm the exact model and dependency artifacts before scheduling. No automatic installation on a customer machine is included.
Provision approved dependencies and models before offline operation; verify their origin and checksums. Keep the runtime on loopback, use one isolated account/instance, disable remote inference, and apply host egress restrictions. Retain raw outputs and source evidence only in an agreed protected location. Agree retention, report redaction and removal of indexes, caches and logs. Local state can contain plaintext source; deletion is not certified secure erasure.
The application has no enterprise source ACL enforcement, OS sandbox or formal security certification. Experimental agent edits and command execution are outside this evaluation. No confidential files or credentials should be sent by email.
Deliverables and acceptance
- A configuration manifest: repository commit, AndesCode revision, model/dependency versions and hashes, hardware and controls.
- An evidence pack: original questions, unedited answers, retrieved sources, missing context, failures and per-run timings.
- A reviewer scorecard and concise adopt, revise or stop recommendation, including unresolved risks and reproduction steps.
Deliverable acceptance means the agreed pack is complete and traceable, including failed runs. Product suitability is a separate decision against the frozen rubric. Customer review and any corrections follow the written scope; a failed evaluation is reported honestly.
Proposed commercial structure
Use a fixed-scope, fixed-fee evaluation with two written milestones: readiness confirmation, then execution and the evidence report. Agree the fee, payment terms, time cap, review period, access/license conditions and cancellation terms before starting. Any wider pilot or agent trial requires a separate scope.
This is a proposal for discussion. It creates no customer commitment, delivery date or usage rights. No installation, meeting or paid work is booked by an enquiry.
To discuss fit, share only your stack, hardware and non-confidential questions.
andescode@datalogic.tech