Make engineering judgment executable.
LMP turns explicit engineering preferences, trade-offs, and source evidence into signed policy packages that local agent workflows can evaluate.
npx lmp init
A preference becomes a package, a decision becomes a result, and a result keeps its evidence.
Read the protocolFrom preference to decision.
LMP makes a declared policy and its selected scope inspectable, so the result can carry its evidence.
The same review becomes explicit, scoped, and recorded.
- return check(files);
- // scope and rule evidence are implicit+ const findings = check(selectedFiles, policy);
+ // evidence is serialized with the resultBrowse declared points of view.
Inspect provenance and package status before selecting a Mind.
Find the discipline you need.
Ownership, systems safety, and bounded complexity
Explore TypeScriptStrict contracts and maintainable application code
Explore GoReadable composition and explicit error handling
Explore DatabasesData locality, authorization, and migration discipline
Explore InfrastructureReproducible systems and visible operational drift
Explore Agent integrationA local connection with a visible decision boundary
ExploreNo hand-waving in the fine print.
The useful distinction is not whether a tool sounds more sophisticated. It is what the runtime can actually enforce, what it only evaluates, and what still needs an engineer.
No. A script that pastes instructions into an agent context is a passive delivery mechanism; it can be useful, but it cannot prove that the instructions were followed. LMP packages guidance with declared rules, evaluates the selected change, and records the result and its evidence. That is a control-and-evidence loop, not a claim that text injection alone creates enforcement. See the protocol boundaries.
That is the failure mode LMP is designed to expose. The agent still generates the change, but the evaluator checks the selected scope against the active Mind and returns pass, needs_revision, blocked, or evaluation_error. A passing result means the configured checks ran and passed; it does not mean the model was obedient or the code is universally correct. Inspect the result states.
Do not assume LMP makes those actions impossible. Its guarantee is bounded by the adapter, evaluator, scope, and enabled checks. LMP should report missing or unperformed evidence rather than convert it into a pass. Network controls, protected branches, CI, dependency review, and human approval remain necessary for stronger operational guarantees. Read the security boundary.
That is not the promise documented here. LMP evaluates agent-generated changes through a local runtime and evidence boundary; it is not presented as a universal filesystem firewall. Claims about a Rust daemon physically rejecting every write should only be made once that behavior is implemented, tested, and independently demonstrated. Review the architecture.
It is compiler-grade infrastructure for declared policy evaluation, not a replacement for a language compiler. AST checks can catch structural patterns when a supported parser and rule exist, but they cannot infer intent, prove architecture quality, or make an arbitrary engineering preference objective. The exact rule, parser, scope, and evidence artifact matter. See what enforcement means in LMP.
No. Resource ceilings and timing measurements can provide useful operational evidence for a defined workload. They cannot, by themselves, establish maintainability, security, correctness, or production readiness. Any telemetry claim needs a reproducible fixture, workload definition, environment, variance, and a record of what was not measured. See the monitoring limits.
A valid signature can establish artifact integrity and signer identity under the configured trust model. It does not prove that the rule is wise, that its source is authoritative, or that the resulting code is safe. Provenance, review, versioning, and evaluation evidence are separate obligations, not things cryptography magically supplies. Check package provenance.
Yes, if people treat a signed package as unquestionable truth. A signature authenticates bytes; it does not confer universal authority. Minds need visible provenance, declared scope, review, and version history, plus a way to reject or replace them. The system should make judgment inspectable, not hide judgment behind a green check. Read the governance model.
It can. Policy evaluation adds cost, and poorly scoped rules create friction without improving decisions. The meaningful test is whether LMP catches issues reviewers care about with lower noise than the existing toolchain. That requires fixed tasks, repeated runs, latency reporting, and negative results—not a demo score. See what still needs evidence.
No. LMP is an additional, inspectable decision boundary. It does not replace domain ownership, independent tests, security review, deployment controls, or final human and CI authority. If a page says otherwise, it is overselling the protocol rather than describing its current evidence boundary. Read what LMP does not claim.
Reproducible public evidence: the same real-world tasks run with and without LMP, identical model and tool conditions, independent review, security evaluation, cost and latency numbers, failure cases, and artifacts anyone can inspect. The strongest claim should be no stronger than the result proves. “Designed to” and “under test” are more credible than calling an unverified capability hardware-enforced. Review the quality checklist.