Buyer due diligence
This is the public record of how we approach delivery, proof, and handoff. It names what you can inspect now and what a project review should confirm for your specific risk, scope, and procurement path.
We reply within two business days with a fit decision and the smallest responsible next step.
Execution record
We keep scope, technical judgment, and client communication close to the work. The engagement record is designed to make decisions, progress, and the next owner legible throughout delivery.
The proposed outcome, boundary, decision owner, and acceptance evidence are made explicit before implementation begins.
Work is reviewed against the shipped change and the next decision, not reported through a detached status layer.
Source, architecture context, operating notes, and the next owner are part of the delivery record.
Inspectable delivery controls
Buyer-facing interpretation of the public mcp-scan commit log below - controls visible in those changes, not a claimed commercial outcome the repository cannot prove.
False-positive guards plus broader credential and environment-file coverage.
Hermetic tests, current runtime support, and complete build artifacts.
Exact version pins, severity-gated audits, and an inspectable public history.
8 public changes, April to June 2026:
| Commit | Change |
|---|---|
| 71f9753 | fix: harden scanner false-positive guards |
| 2c8114d | fix(ci): include data/ in build artifacts for test stage |
| 381866b | fix(ci): drop Node 18 + exclude pre-existing robustness hang |
| 2f2f349 | fix(deps): pin lodash to 4.17.21 exact, audit gate at critical only |
| 8d0b0a1 | fix(golden-tests): hermetic, machine-portable, stable across runs |
| 820eaed | fix(data-controls): restore token-class API Key keywords |
| b1cfa2a | fix(env-leak): scan all env file variants per directory |
| 53411c5 | fix(lib): sbom is a path string, not a boolean |
The delivery lead stays on the build through the production handoff. The full studio roster is public. See the studio
What delivery can include
Exact inclusions are set in the scoped engagement. These are documented artifacts from the public delivery catalog.
Public evidence
Public evidence has a source and a stated verification boundary. Confidential work remains described at the level that can be responsibly published.
Live in production
Public case study, interface demo with synthetic records, and a live production endpoint. PowerLiens owns the system.
PowerLiens case studyPublic product surface live
The public marketing surface and privacy-screened captures are reviewable. Repository evidence is summarized because the source is private.
Public ProTeach surfaceNDA-protected
The public description is intentionally limited. It does not claim a client identity, outcome numbers, or independent verification.
Work indexPublic
Multiple long-form pieces show implementation detail, tradeoff analysis, and production pitfalls.
Writing indexPublic
The public repository and package can be inspected directly for technical review.
mcp-scan sourcePublic
The profile states the founder's execution lanes and links directly to LinkedIn, GitLab, and the mcp-scan npm package. Commit history and post dates remain visible at those sources.
Founder profileProject-review boundary
A public website cannot answer every procurement question truthfully. The project review is where the proposed work is made specific without publishing client-sensitive details or generic assurances.
The proposed boundary, milestones, exclusions, and evidence that would show the work is ready.
Who owns the technical decisions, the direct communication path, and the review cadence for the proposed engagement.
Which security, access, confidentiality, and commercial questions are relevant to the proposed scope.
Whether the proposed scope needs specialist capacity or third-party dependencies beyond the work described publicly.
Next decision
Share what is blocked, what is already true, and what needs to be safe when it ships.
Request a project review