Evidence and authority, with clear boundaries.

An architecture overview, with current status

This page explains Remedy’s intended trust boundaries and current product foundation. It is not a certification, penetration-test report or guarantee that every deployment has passed a security assessment. Remedy is in early access. Reporter, SDK and the diagnosis, repair and verification loop are described as core foundations, not a promise of turnkey availability for every project. The Agent is in development; Probes are planned expansion; repository and observability connectors have individual availability constraints. Check the integration status table before choosing a workflow.

Collect evidence for a defined purpose

The Reporter and SDK foundations are designed around bounded application evidence, sanitisation and credential rejection. A project determines what context is appropriate to collect. Raw reports and diagnostic text are treated as evidence to inspect, not as authority to run commands or alter source.

For onboarding, agree which fields can be captured, who may access them, where they are processed and how long they are retained. Screenshots and logs need particular attention because they can contain information unrelated to the incident. Product-specific terms should describe the actual configuration.

Keep repository identity and execution scope explicit

A repair should refer to an authorised repository and exact baseline commit. The candidate workspace is intended to be isolated from the live application. Dependencies, test fixtures and tool access still need to be defined for that environment.

A reviewer should see the proposed diff and the evidence from configured checks. Missing checks and failed attempts remain relevant. The ability to inspect a repository is separate from permission to write a branch, merge a change or deploy it.

Give runtime actions their own policy

The developing Agent model uses named capabilities and outbound communication. Observation and operational action are separate decisions: access to service status does not by itself authorise changing the service. The exact permitted action list needs to be assessed for the installed configuration.

An operational recovery and a permanent code repair may have different approvals and success criteria. The incident record should preserve which action occurred and what evidence it produced. Read the remediation policy model for this distinction.

Bind review to the change being released

The person responsible for approval needs the actual candidate and its check results. A later change can invalidate the earlier review or test evidence. Release controls should therefore preserve the relationship between approved source and deployed source.

Remedy’s verification direction is to repeat an incident-specific check after release and retain the result. A merged change is a milestone; an observed recovery is another. Read verified software repair for the intended outcome model.

Evaluate the complete data flow

Repository hosting, repair execution, model inference and the control plane may have different locations and responsibilities. Agree those boundaries, provider terms, access revocation and operational recovery before sharing sensitive project data. The self-hosting guide provides a detailed checklist.

For an initial architecture discussion, email hello@aibugfixer.online with a non-sensitive outline of your environment. Product data terms and supported controls will be agreed for the early-access scope.