What You Can Rely On in an EEI Seeq Connector¶
A connector built into Seeq comes with an expectation you rarely have to think about. It is built the way Seeq builds software, validated with every Seeq release, delivered with the platform, and supported by Seeq.
A connector from anyone else has to earn that expectation. This page shows how an Endeavor Engineering connector does, one concern at a time, with where to find the evidence, and what is not in place yet. It is written for the people who have to approve a connector: your architects, IT and operational technology (OT) teams, security reviewers and procurement.
About the comparison. This page states what EEI does and can show. It does not describe Seeq's internal process, and it does not imply that Seeq endorses or certifies EEI's connectors.
Concern by concern¶
| You would want to know… | What EEI does | Where to check |
|---|---|---|
| Is it built the Seeq way? | On Seeq's own Connector SDK, through one shared EEI foundation that implements the indexing lifecycle once for every connector | Connectors ++ |
| Will it keep working as Seeq ships releases? | Every week, automation checks each connector against Seeq's newest Connector SDK release, assesses the change against the Seeq API the connector actually uses, then builds and tests against it | Validating Seeq Integrations |
| Will it load on our Seeq agents? | Every release states the oldest Seeq agent it supports, is tested there every week and at release, and is checked against your agent before it is delivered | Validating Seeq Integrations · Reading an EEI Version Number |
| Does it meet Seeq's connector contract? | Seeq's own standard conformance tests run against it, at the current Seeq line and at the oldest supported one | Validating Seeq Integrations |
| How thoroughly is it tested? | Five tiers, from unit tests to live acceptance against a real source system, with shared expected results asserted by both the offline and the live tests | Compliance posture |
| Can a bad build reach us? | A release is a deliberate act, and the release build is the gate: a failing test or a failed build at the oldest supported agent stops it. Every release is tagged, so its exact source is recoverable | How We Build, Release and Deliver |
| Can you prove a release was tested? | Each test run produces an evidence bundle, with the results, a hash of every file tested, and who ran it, kept in encrypted storage under a 365-day retention lock | How We Build, Release and Deliver |
| Is what we install what you released? | Immutable, integrity-verified packages, published from the pipeline, with no stored cloud keys in it | How We Build, Release and Deliver |
| How is it licensed? | A signed license bound to your host, working fully offline, issued under restricted, recorded access | Licensing |
| How does it treat our source systems and network? | One shared network layer: retry with backoff, adaptive concurrency and circuit breaking, so a struggling source is not made worse | How EEI Connectors Behave on Your Network · For Your IT Team |
| Can we see how it is doing? | Each connector publishes its own health and indexing activity into Seeq, beside the data it produced | Connectors ++ |
| Who supports it? | EEI, with a response within one business day unless other arrangements are made. Where you buy through Seeq, Seeq is your first contact and EEI stands behind it | Getting Support from EEI |
| Is your engineering secure? | Identity-based access, short-lived credentials in the pipeline, secrets never in source code. SOC 2 Type II is the target; EEI is not certified yet | Security posture · Compliance posture |
What if EEI is small?¶
It is a fair question to ask of any specialist supplier. EEI's answer is structural rather than a promise:
- One foundation. A change in Seeq is absorbed once, in the shared layer, for every connector, not connector by connector.
- One pipeline. Every product is built, tested and released the same way, so an improvement reaches all of them at once.
- Written down. Engineering decisions and procedures are recorded, and releases are reproducible from tagged source, so the knowledge does not live in one person's head.
- A partner in front. Where you buy through Seeq, Seeq remains your first line of support.
- A path to tighter coverage. Support commitments tighten as EEI grows, on terms agreed in advance, and are never reduced.
Where this stands, honestly¶
| Status | |
|---|---|
| The weekly check against Seeq's newest SDK, with builds and tests at the new release and the oldest supported agent | In place |
| Seeq's conformance tests, and the release gate | In place |
| Retained, attributable test evidence | In place; making it mandatory for every release comes before the next release |
| End-to-end testing through a live Seeq agent and server | In place, run by an engineer for each release; automating the comparison of what Seeq receives comes before the next release |
| Signed, host-bound, offline licensing | In place |
| Installing and upgrading | Managed by EEI, manual by design |
| Automatic, entitlement-governed updates | Being built |
| Watching deployed connectors across sites through VirtualForge | Planned |
| SOC 2 Type II | Target, not yet certified |