one platform two pillars
byndr closes the text gaps in your EPLAN article database with a reviewed, validated loop — and routes EPLAN events to where your team actually looks. the cloud never writes to EPLAN directly.
byndr is a unified EPLAN platform. Both pillars share one tenant, one auth model, and the same hard boundary: the cloud never writes to EPLAN directly.
Close the gaps in your article data.
Ingest a read-only snapshot of your EPLAN article database. An LLM closes text gaps — translations, descriptions — against deterministic validators. Every change is reviewed like a pull request; a local client writes approved values back into EPLAN.
Route EPLAN events where the team looks.
A PDF export, a BOM change, a project event — captured next to EPLAN and routed to the destinations your engineering team already watches: Microsoft Teams, email, a shared drive, or a plain webhook you control.
Gappy article data
Missing translations and descriptions patched by hand — spreadsheet round-trips, inconsistent wording, and gaps that differ language by language.
One-off local macros
Export scripts living on a single workstation. You own the maintenance forever, and they break when a colleague changes machines.
Events trapped on the desktop
A PDF or BOM export never leaves the CAD PC. Nobody downstream sees it unless someone remembers to attach it somewhere.
A reviewed enrichment loop
The LLM proposes, deterministic server-side validators decide, and a human approves each change like a pull request — nothing is guessed into your database.
Configured routes, not code
Point an EPLAN event at a destination and you're done. Turn a PDF export into a Teams notice or a webhook call in minutes.
The cloud never writes EPLAN
byndr produces proposals and a write queue only. A small local client applies human-approved changes back into EPLAN — that boundary is a hard invariant.
The gym is a loop, not a batch job. An LLM proposes text values; a deterministic validator is the only thing that can accept them; a human signs off before anything is written back.
A read-only copy of your article database is ingested into your private tenant. Real data stays yours — it never enters our repository.
Through an MCP server, a model reads article context and submits a value for a missing translation or description. It only ever proposes.
Deterministic, server-side checks accept or reject each value. The model proposes; the server decides. No value is taken on trust.
A human approves or rejects each proposal. Approved ones enter a write queue; rejected ones close the loop with feedback.
A small client next to EPLAN polls the queue and applies only approved changes. The cloud never writes to EPLAN directly.
overlay, never mutation — the gym's only output is proposal rows. your ingested data is read-only.
Each event maps to a real EPLAN API action — including the ones most integrations never touch.
pdf-exported
targeted
PDF exported
Fires when a schematic or documentation PDF is exported from a project.
action export · PDF
bom-exported
targeted
BOM / parts list exported
Fires when a bill of materials, parts list or terminal label is exported.
action label
project-closed
targeted
Project closed
Fires when a project is closed — useful for sign-off and archival flows.
event lifecycle
dxf-dwg-exported
coming soon
DXF / DWG exported
Fires when pages or the project are exported to DXF or DWG for mechanical or client hand-off.
action export · DXF/DWG
project-backed-up
coming soon
Project backed up
Fires when a project backup (.zw1) is created — ready for off-site archival.
action backup
wiring-exported
coming soon
Production wiring exported
Fires when production wiring data is exported for the machine build.
action ExportProductionWiring
Microsoft Teams
Post a message to a channel on every event.
Send the export to a distribution list or an inbox.
Shared drive
Drop the exported file onto a network share via a small local agent.
Webhook
POST the payload to any HTTP endpoint you control — forward it anywhere.
no slack — by design. OT and engineering teams run on Microsoft Teams, email and their own file shares. A generic webhook forwards the payload anywhere else.
Both pillars share the same shape: lightweight clients on the desktop, a per-tenant cloud that coordinates, and a hard rule that only a local client ever writes to EPLAN.
A snapshot client, an event client, and a write client — each doing one small job on the machine that runs EPLAN. Nobody changes how they work.
Per-tenant, byndr ingests articles, runs the gym's deterministic validators, dispatches events, and holds the write queue. Credentials stay server-side.
The write client polls for human-approved changes and applies them in EPLAN. The cloud never writes to EPLAN directly — that boundary is fixed.
No pricing yet, and no sign-up wall. If you run EPLAN and want to try the data loop or the automations, join the early-access list and help shape what ships first. Early members help set where this goes.
byndr runs on Cloudflare (Workers + D1 + Durable Objects). Deploy it to your own account, or wait for the hosted option.
One tenant, one auth model, both pillars. Your setup is isolated from everyone else's.
Real article data lives in your private database — never in our repository. The gym only ever proposes.
Want in? Send a note and tell us which pillar matters most to your team.
request early accessplaceholder — no numbers, no tiers, no commitments. this page describes an early-access product under active development.
EPLAN Electric P8 is the first target. The clients are small and single-purpose, and the platform is designed so other EPLAN tools and event sources can be added the same way.
No. The cloud only produces proposals and a write queue. A local client next to EPLAN applies human-approved changes. That boundary is a hard invariant — nothing in the cloud touches EPLAN directly.
The LLM only proposes. Deterministic, server-side validators decide whether a value is acceptable, and a human reviews every proposal like a pull request before anything is queued. The gym is overlay-only: it never mutates your ingested data.
In your own per-tenant database. Real article data never enters our repository — you bring your own, and it stays yours.
Because OT and engineering teams don't run on Slack. byndr targets the tools they actually use — Microsoft Teams, email, and shared drives — with a generic webhook for anything else.
Yes. byndr runs on Cloudflare (Workers + D1 + Durable Objects); you can deploy it to your own account. It's open source under the MIT licence, and a fully-local runtime is on the roadmap.