Moysis Moyseos

Reading receipts, checking the output

A receipt scanner that turns a photo into itemized purchase data, then checks the model’s output against the scanned text. Everything runs locally.

My contribution

Designed and implemented. I wrote the local extraction flow and the checks around the model’s output.

Status

Local prototype. The local flow covers receipt extraction, validation and review.

Project material

A project write-up covering the extraction flow, validation checks and receipt example.

Checking the extraction against the receipt.

The validation work began with an unreadable receipt: the model returned 15 purchases drawn from examples in its prompt. I used that case to develop checks that caught all 15 unsupported items in the example.

Low-confidence scans are rejected before the model runs, and empty receipt sections are skipped. For each item the model returns, the grounding filter looks for a matching word in the scanned text, allowing one character of OCR error in words at least four characters long.

The extracted amounts are also checked against the printed total. A mismatch is flagged for review rather than silently accepted.

Scope and context

The checks flag entries for review by comparing them with the scan. Photo quality and model output still affect the result, and a text match does not establish that every item or price is correct. The 15-item example is a documented test case rather than a general accuracy benchmark.

Giving coding agents room to work

Several AI coding agents work on one codebase in separate working copies. A supervisor can retry a failed task, reassign it or ask a person to step in.

My contribution

Designed and implemented. I wrote the coordination code and revised the file-tool checks after finding the escape paths.

Status

Coordination prototype. Parallel execution, task recovery and file-tool path checks are implemented.

Project material

A project write-up explaining agent coordination, recovery and the isolation design.

Separate working copies, with explicit file boundaries.

Setting an agent’s working directory didn’t stop it from passing an absolute path outside that directory to a file tool. Comparing path strings wasn’t enough either: a symlink could point somewhere else.

The check now resolves the real path of each path-bearing file-tool argument before comparing it with the assigned working copy. The list of path fields comes from configuration, so the check isn’t tied to a hardcoded list of tools.

The Claude Agent SDK handles the agent sessions; the surrounding code manages working copies, execution and recovery. The changes address path-based escapes and document the separate requirements for shell isolation.

Scope and context

The containment checks cover file-tool arguments, including paths reached through symlinks. Arbitrary Bash commands can still reach outside the assigned working copy through commands such as cd or cp. Shell isolation requires an OS-level sandbox and remains a documented, deferred part of the design.

Showing the support behind an answer

A document-chat interface that displays answers and support labels returned by a separate retrieval and grading workflow.

My contribution

Designed and implemented. I connected document ingestion and chat to the interface, including the response status and warning details.

Status

Interface implemented. Document upload, chat and response-status display are implemented in the interface.

Project material

A project write-up covering the interface and its connection to the retrieval and grading workflow.

Making an answer’s source support visible.

This project covers the document-upload and chat interface. It connects to a separate n8n workflow for retrieval and grading; that workflow is outside this repository. The interface presents the returned answer, support status and warning details.

The interface makes room for the full range of responses: an answer may be fully supported, partly supported, unsupported, or have no good answer in the documents.

Support information appears alongside the answer, with further details available to the reader. This keeps the context for judging a response close to the response itself.

Scope and context

Running the complete document-chat flow requires the separate retrieval and grading workflow. Its support labels are model-generated guidance for the reader, rather than independent verification of an answer’s correctness.

Capturing a web page through an API

A self-hostable service that takes a URL and returns a screenshot, PDF or archived page, using headless Chromium behind a job queue.

My contribution

Designed and directed. I worked from a specification and directed implementation with an AI coding agent.

Status

Capture service implemented. The API and capture worker are implemented, with integration checks. This entry covers the implementation rather than a public deployment.

Project material

A project write-up covering the capture architecture, address policy and integration checks.

Checking addresses before opening the browser.

A URL-fetching service can be asked to reach internal addresses that the caller couldn’t access directly. The specification treated that as a starting constraint, with an address policy covering private, link-local and cloud-metadata addresses.

The API queues a capture and a separate worker runs Chromium. The implementation includes address-policy tests, along with checks for API contracts and webhook delivery.

Scope and context

The implementation covers the capture API, browser worker and integration checks. Reliability under production load has not been established. Individual human and agent implementation contributions are not fully attributed here.

Checks permissions before retrieval

A document-access foundation that resolves which records a person may read, designed to sit before retrieval for an AI answer.

My contribution

Specified and directed. I wrote the specification. An AI coding agent implemented the schema and permission foundation.

Status

Access-control foundation. Schema and permission checks implemented as the first part of the wider document-access design.

Project material

A project write-up covering the schema, permission tests and boundary between access control and retrieval.

Access decisions before model context.

The design puts the check before any data reaches the model, rather than adding an instruction telling the model to behave. The implemented foundation resolves which records a caller is allowed to read; access is denied unless a rule allows it.

The policy tests pair an authorized reader with an unauthorized reader, covering both permitted access and denied requests.

I wrote the specification and directed an AI agent’s implementation of the schema and permission checks. This establishes the access-control layer described in the design.

Scope and context

The implemented scope is the schema and permission checks. Retrieval and AI answering are not implemented, so the project demonstrates the access-control foundation rather than an end-to-end assistant.

The work behind a contact form

A contact endpoint for a local-business site that stores submissions, checks for abuse and sends email and CRM notifications.

My contribution

Contact-flow development. I developed the intake protections and notification handling on top of an AI-generated site scaffold.

Status

Deployed site. The contact endpoint is part of a site deployed to an edge network.

Project material

A project write-up covering intake protections, submission handling and notification behavior.

Keeping submissions and notifications independent.

I hardened the intake path on top of an AI-generated site scaffold. Country filtering happens at the edge, followed by form bot verification and rate limiting keyed on a salted hash of the visitor’s address. The application stores the hash, not the raw address.

Email and CRM notifications are handled independently, so a failed CRM request doesn’t turn the submission into an error or prevent the email from being attempted.

Scope and context

The entry focuses on the contact endpoint within the deployed site. Its fallback rate limiter operates per running instance when the shared store is unavailable. Automated endpoint tests are not included.

Comparing approaches to fraud detection

Coursework revisited as a fraud-detection service, with decisions weighted by the cost of approving, declining or reviewing a transaction.

My contribution

Authored with agent contributions. My contribution spans the original coursework and later development. The repository also contains AI-agent commits; their individual scope is not fully attributed here.

Status

Research prototype. The project includes offline evaluation, cost-aware decision logic and FastAPI serving code.

Project material

The public repository includes the code and a review of the earlier methodology in IMPROVEMENTS.md. View repository

Comparing decisions by their cost.

The project grew from coursework into a closer look at evaluation and decision costs. I reviewed the earlier methodology and documented test-set threshold selection and inconsistent cross-validation scaling by file and line in IMPROVEMENTS.md. The original code remains available alongside those notes.

Later work added a FastAPI service and cost-aware decisions. Comparing the approaches showed that reinforcement learning did not consistently outperform a simpler threshold on individual transactions. It showed a stronger result in an offline sequential-fraud scenario, where earlier transactions affect the decision.

The comparison separates individual transaction decisions from sequential ones, making the conditions behind each result explicit.

Scope and context

Evaluation uses offline data; the comparisons do not establish performance on live transactions. The repository preserves the earlier coursework and its documented methodology issues. Automated tests and CI are not included, and an end-to-end deployment is not documented.