Larry Ross@ldrfulcrum555
4
Events attended
3
Submissions made
United States
1 year of experience
About me
I’m Larry David Ross, also known as Big L. I’m the founder of Fulcrum Fortress Consulting, where I design practical AI systems, agent workflows, and operational infrastructure for real-world business use. My work sits at the intersection of systems architecture, business operations, automation, and responsible AI. I’m especially interested in systems that can maintain context, coordinate specialized capabilities, recover from failure, and execute useful work while keeping people accountable for consequential decisions. I’m a hands-on builder, so I spend a lot of time turning concepts into working prototypes and testing how they behave outside ideal conditions. I’m particularly interested in agent coordination, memory, WebMCP and agent-operable software, observability, reliability, and human-in-the-loop system design. I enjoy connecting with other builders, comparing architectures, testing projects, exchanging feedback, and learning from people solving difficult technical and operational problems. Glad to be here and interested to see what everyone is working on.
🤝 Top Collaborators
.png&w=640&q=75)
🤓 Latest Submissions
Fulcrum Service Recovery
Big delivery platforms run automated customer-recovery engines in-house. A 3–30 location restaurant group handles complaints by hand, from memory, under time pressure: slow, inconsistent, and refunds drift from policy. Fulcrum Service Recovery gives small groups that capability without handing decisions to a bot. Staff paste one or many complaints, optionally attach an anonymized order CSV, and pick a versioned written policy. AMD Developer Cloud Token Factory runs DeepSeek-V4-Flash (OpenAI-compatible API, temperature 0.2, JSON-only) to extract the issue, order refs and missing facts, and to draft a reply. Deterministic code then decides what is allowed: order verification, policy caps, never-automate rules, complaint-vs-record conflicts, and prompt-injection detection. Each case becomes a manager review packet: the draft (or why none was released), evidence refs for every claim, missing facts, inference provenance (backend, model, request ref) and an audit trail. Model error, timeout or bad JSON fails closed to manager review, with no silent fallback. Managers approve, reject or request info; decisions only record an audit event. Results on the live AMD backend (20-case synthetic eval): 20/20 correct routing, 100% packet completeness, 0 unauthorized side effects; median latency 6.24 s, p95 11.50 s on the shared endpoint. Built for shared capacity: 429 backoff honoring Retry-After, request timeouts, and a dedicated MI300X provider slot ready to configure. Next: MI300X deployment, a larger eval set, an owner policy editor, and a pilot with a restaurant group on its own written policy. All data is synthetic; no refunds, messages or customer contact. Stack: FastAPI, Pydantic, SQLite, Docker.
18 Oct 2026
Dark Fulcrum Force
Dark Fulcrum Force is our tablekeeper entry for the WeAreDevelopers × BAND Dark Factory hackathon: an autonomous "factory" of six coding agents that turns one operator dispatch into shipped, verified software with no human in the loop afterward. The band has six seats, each with one job and a generic mandate that carries no track-specific details — the specifics live only in the dispatch, so the same mandates work on any project. FORGE plans the work and issues sealed handoff packets; each packet's hash covers the spec, base revision, target seat, and a lease built from handoff and attempt numbers, and every receiving seat verifies the seal before acting. HAMMER and ANVIL implement the same stage independently — one in Python, one in Node, on different models — without seeing each other's code. PROBE runs the supplied tests plus its own probes against each build; CONTRA attacks both adversarially; WARDEN keeps the full evidence trail. In the run that produced this submission, the operator created and bound the seats, then posted one dispatch at 9:15 PM Central — the only human message in the room. Review caught a defect in one build; ANVIL's repaired build passed the checks and became the merged base. The result is tablekeeper, a restaurant reservation service built so a table is never double-booked under concurrency, retries, and time zones. It builds and serves from a clean container with no outbound network and passes all 120 shipped Stage 1 checks. Everything — the factory, the mandates, the room recording, and the code — is in the public repo.
6 Oct 2026
Contradictor: Evidence Before Acceptance
AI-assisted development can produce convincing completion claims before a team has reproducible evidence. Contradictor addresses the testing and repair handoff: developers need to know what failed, which build was tested, what changed, and whether the same challenge passes after repair. Fulcrum Force built a local developer workflow around IBM Bob IDE. An operator freezes a requirement and admits an independently authored challenge. A FastAPI backend executes the challenge; Contradictor binds the results to candidate and challenge identities, preserves stdout/stderr and structured evidence, and exports a review package. A confirmed finding becomes a bounded Bob repair packet. The same frozen challenge then runs again, and an independent reviewer makes the technical determination. Our self-case study challenged Contradictor itself. A plan could inherit authorization from its prototype. The frozen F9 challenge exposed that behavior: 29 of 30 tests passed and F9 failed. Bob added an own-property guard without weakening the challenge or existing authorization checks. The unchanged challenge then passed 30/30, including the legitimate own-property positive control. One of those 30 cases is an explicitly deferred observational check, not a resolved defect. Independent BUILD reproduction exercised both candidates through the live backend and confirmed the failure-to-pass transition. The accepted integrated candidate also passed typecheck, 146 Node regression tests, and eight backend tests. Evidence stays attributable to its actual executor; Bob's shell was unavailable, so Bob did not execute these checks. The prototype demonstrates a repeatable way to inspect failure, route repair, compare reruns, and distinguish test success from acceptance. We do not claim a measured productivity percentage. It is a trusted-local prototype, not a hostile-code sandbox or production authorization system. Acceptance covers the frozen HC-B01/F9 scope only; HC-B02 through HC-B05 and the zero-width-space policy are deferred.
27 Sep 2026
