I build software systems where AI, security, and product engineering meet.

How it works

1. 1Field reportStaff file an issue from the mobile app.
2. 2ValidationThe report is checked and geo-matched to the nearest outlet.
3. 3BackendStored with spatial data and an auditable history.
4. 4AssignmentRouted through the organisation role hierarchy.
5. 5NotificationThe responsible role is pushed the issue.
6. 6ManagementThe dashboard shows what is still outstanding.
7. 7ResolutionClosed with the trail intact.

Evidence

Limitations

• Client-owned system; the repository and operational data cannot be made public.

How it works

1. 1ScanRead the dependency tree of the project.
2. 2DetectIdentify advisories affecting resolved versions.
3. 3Select remediationChoose a candidate upgrade to test.
4. 4Isolated copyApply the change to a copy, never the working tree.
5. 5Docker verificationRun the check in a controlled container.
6. 6RescanConfirm the advisory no longer resolves.
7. 7Build & testCheck the fix did not break the project.
8. 8EvidenceEmit a report of what was observed.

Evidence

Limitations

• Network isolation is bridge-level, not domain-level: during the install phase the container has general egress, so the real defence against a malicious postinstall is that lifecycle scripts are disabled, not the network boundary.
• A confidence verdict reflects the project's own build and test commands exiting successfully, not whether those checks are honest. The re-scan independently confirms the vulnerability is gone; it does not re-verify the project's test assertions.
• Docker containers share the host kernel, so a container-escape vulnerability in the runtime itself is outside what this can mitigate.
• Verification and update replay fixes with npm; yarn and pnpm projects are refused rather than risking lockfile corruption.

How it works

1. 1QuestionA query is posed against the corpus.
2. 2Retrieved evidenceThe system returns what it can find.
3. 3Evidence deficiencyThe evidence is typed: missing, insufficient, conflicting, outdated, or absent from the corpus.
4. 4Repair actionA candidate response is selected for that deficiency.
5. 5EvaluationEach pairing is run under the same controlled conditions.
6. 6ResultThe factorial has been executed and the analysis completed.

Evidence

Limitations

• One corpus, one language, and a 250M-parameter local reader, so absolute numbers are not comparable with published RAG systems; the factorial is a within-instance contrast.
• Every conflict result is scoped to constructed, resolvable conflict. Natural, unresolvable conflict is in the benchmark for detection only.
• Constructed conflict is far easier to detect than natural conflict — recall 0.957 against 0.574 — so detection results do not generalise from the constructed set.
• The benchmark fails its own surface-leakage gate on detection for some types, and the failure is reported rather than repaired.
• The only cell surviving multiple-comparison correction was later found to be measuring a construction artifact rather than conflict resolution; the pre-registered replication that would settle it has not been run.
• The HotpotQA replication factorial has not been completed.

How it works

1. 1DiscoveryNearby peers are found over BLE.
2. 2PrepareThe message is framed for transport.
3. 3EncryptEncrypted before it leaves the device.
4. 4TransferHanded to a peer within range.
5. 5Store & forwardHeld on the device until a link exists.
6. 6AcknowledgeDelivery is confirmed where the path supports it.

Limitations

• Protocol, routing, cryptography, persistence and the native BLE transport are built and tested, but the user interface is at an early stage.
• Not yet installable as a finished product, and not suitable for real emergencies.
• Real multi-hop relay across physical devices is not yet fully validated.

How it works

1. 1Read the codebaseUnderstand conventions written by someone else.
2. 2Scope the changeKeep the diff small enough to review.
3. 3Open the PRSubmit it to the maintainers.
4. 4ReviewRespond to the project’s standards, not your own.
5. 5MergeThe change lands upstream.

Pull requests

• AcademySoftwareFoundation/dna#195merged
• cobusgreyling/loop-engineering#437merged
• cobusgreyling/loop-engineering#395merged
• pydantic/pydantic-ai#5969merged
• promptfoo/promptfoo#9781merged
• MCP-Audit/MCTS#233merged
• shaal/eye-tracker#61open