eric-sdk 0.1.5 → 0.1.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/CHANGELOG.md +42 -42
  2. package/README.md +52 -50
  3. package/package.json +9 -2
package/CHANGELOG.md CHANGED
@@ -2,21 +2,38 @@
2
2
 
3
3
  All notable changes to the Eric SDK are documented here.
4
4
 
5
- This project follows semantic versioning.
6
- Pre-1.0 releases may introduce intentional breaking changes as the API surface evolves.
5
+ This project follows semantic versioning.
6
+ Pre-1.0 releases may introduce breaking changes as the API surface and governance model stabilize.
7
7
 
8
8
  ---
9
9
 
10
- ## [0.1.5] – 2026-02-24
10
+ ## [0.1.7] – 2026-05-06
11
+
12
+ ### Documentation
13
+
14
+ - Rewrote README to better reflect the SDK's role as an execution control layer.
15
+
16
+ **Rationale:** The previous README underemphasized the governance model and led with authentication rather than how the SDK actually works. Updated to open with the execution pipeline, added a "How it works" section covering all five enforcement steps, expanded the security section with specific properties, and restructured usage examples to lead with a complete quick start. No runtime behavior changes.
17
+
18
+ ---
19
+
20
+ ## [0.1.6] – 2026-02-25
11
21
 
12
22
  ### Changed
13
23
 
14
- * Narrowed `type` in response shape from `string` to `"structured" | "text"`.
24
+ Added `repository`, `homepage`, and `issues` metadata to `package.json`.
25
+
26
+ **Rationale:** Improves npm package transparency by linking the SDK to its public GitHub source, issue tracker, and documentation. No runtime behavior changes.
27
+
28
+ ---
29
+
30
+ ## [0.1.5] – 2026-02-24
31
+
32
+ ### Changed
15
33
 
16
- ### Rationale
34
+ - Narrowed `type` in response shape from `string` to `"structured" | "text"`.
17
35
 
18
- Response format classification is now explicitly constrained.
19
- This prevents accidental drift in output types and strengthens the SDK’s deterministic contract.
36
+ **Rationale:** Response format classification is now explicitly constrained. Prevents accidental drift in output types and strengthens the SDK's deterministic contract.
20
37
 
21
38
  ---
22
39
 
@@ -24,73 +41,56 @@ This prevents accidental drift in output types and strengthens the SDK’s deter
24
41
 
25
42
  ### Changed
26
43
 
27
- - Added `engines` field specifying Node.js >=20.
44
+ - Added `engines` field specifying `node >=20`.
28
45
 
29
46
  ---
30
47
 
31
48
  ## [0.1.3] – 2026-02-06
32
49
 
33
- ### Changed:
34
-
35
- * **Removed `client` from request payload**: The SDK no longer includes `client` in the request body when calling `decide()`.
36
-
37
- ### Rationale:
50
+ ### Changed
38
51
 
39
- `client` is infrastructure identity and is now treated as authoritative header-only metadata (`x-api-client`).
40
- This change removes ambiguity, prevents spoofing, and aligns the SDK with Eric’s control-plane model, where execution authority lives outside user-provided input.
52
+ - Removed `client` from the `decide()` request payload.
41
53
 
42
- ### Notes:
54
+ **Rationale:** `client` is infrastructure identity and is now treated as authoritative header-only metadata (`x-api-client`). Removing it from the request body prevents spoofing and aligns the SDK with Eric's control-plane model, where execution authority lives outside user-provided input.
43
55
 
44
- * Applications must continue to provide `x-api-client` and `x-api-key` headers.
45
- * Requests that previously included `client` in the body may be rejected by strict API validation.
56
+ **Note:** Requests that previously included `client` in the body may be rejected by strict API validation.
46
57
 
47
58
  ---
48
59
 
49
60
  ## [0.1.2] – 2026-02-03
50
61
 
51
- ### What's New:
52
-
53
- * **Updated API Endpoint**: The SDK now calls the API endpoint at `https://us-central1-eric-ai-prod.cloudfunctions.net/decide` for decision-making flows.
62
+ ### Changed
54
63
 
55
- ### Breaking Changes:
64
+ - Updated API endpoint to `https://us-central1-eric-ai-prod.cloudfunctions.net/decide`.
56
65
 
57
- * **Endpoint Change**: If you were using the previous `decide` endpoint, please update the SDK configuration to use the new endpoint.
66
+ **Note:** If you were calling the previous endpoint directly, update your SDK to this version.
58
67
 
59
68
  ---
60
69
 
61
70
  ## [0.1.1] – 2026-01-30
62
71
 
63
- ### Changed:
64
-
65
- * Removed explicit `flow: "decisionRouter"` from SDK requests.
72
+ ### Changed
66
73
 
67
- ### Rationale:
74
+ - Removed explicit `flow: "decisionRouter"` from SDK requests.
68
75
 
69
- The Eric API no longer accepts direct flow invocations.
70
- All requests are now treated as intent submissions and are routed through the internal decision router by default. This change simplifies the SDK payload and prevents accidental coupling to internal execution details.
76
+ **Rationale:** The Eric API no longer accepts direct flow invocations. All requests are now treated as intent submissions and routed through the internal decision router by default. Simplifies the SDK payload and prevents coupling to internal execution details.
71
77
 
72
78
  ---
73
79
 
74
80
  ## [0.1.0] – 2026-01-27
75
81
 
76
- ### Changed:
77
-
78
- * Removed `client.call()` to prevent direct flow invocation.
79
- * All executions must now be routed through `decide()`.
82
+ ### Changed
80
83
 
81
- ### Rationale:
84
+ - Removed `client.call()`. Direct flow invocation is no longer supported.
85
+ - All executions must now be routed through `decide()`.
82
86
 
83
- Direct flow execution allowed applications to bypass policy enforcement. Eric is designed as a governance and control layer, and all execution must pass through policy evaluation to ensure deterministic, auditable outcomes. This release intentionally narrows the public API to reflect Eric’s execution model.
87
+ **Rationale:** Direct flow execution allowed applications to bypass policy enforcement. Eric is a governance and control layer — all execution must pass through policy evaluation to ensure deterministic, auditable outcomes. This release intentionally narrows the public API to reflect that model.
84
88
 
85
89
  ---
86
90
 
87
91
  ## [0.0.5] – 2025-12-14
88
92
 
89
- ### Added:
90
-
91
- * Initial public SDK release.
92
- * `decide()` with policy-based routing and optional execution bounds.
93
-
94
- ---
93
+ ### Added
95
94
 
96
- This version ensures clarity and consistency across all sections while providing users with the necessary context on each update.
95
+ - Initial public SDK release.
96
+ - `decide()` with policy-based routing and optional execution bounds via `allowedFlows`.
package/README.md CHANGED
@@ -1,11 +1,10 @@
1
1
  # Eric SDK (JavaScript / TypeScript)
2
2
 
3
- Official SDK for interacting with **Eric AI**, a policy-governed execution layer for AI systems.
3
+ Official SDK for **Eric AI** — the execution control plane for production AI systems.
4
4
 
5
- Eric is designed for environments where AI behavior must be **controlled, deterministic, and auditable**.
6
- All requests are evaluated against configured policy before any capability is executed.
5
+ Every request is evaluated against declared policy before any capability executes. No model is invoked until intent is classified, policy is cleared, and a registered capability is matched. Every execution — allowed or blocked — is logged with an immutable audit trail.
7
6
 
8
- This SDK exposes a single, safe interaction model that enforces those guarantees by default.
7
+ Built for environments where AI behavior must be **controlled, deterministic, and auditable**.
9
8
 
10
9
  ---
11
10
 
@@ -15,11 +14,11 @@ This SDK exposes a single, safe interaction model that enforces those guarantees
15
14
  npm install eric-sdk
16
15
  ```
17
16
 
18
- ---
17
+ Requires an Eric-issued API key. [Request access →](https://ericaicontrol.dev)
19
18
 
20
- ## Authentication
19
+ ---
21
20
 
22
- You will need an Eric-issued API key.
21
+ ## Quick start
23
22
 
24
23
  ```ts
25
24
  import { EricSDK } from "eric-sdk";
@@ -28,41 +27,38 @@ const eric = new EricSDK({
28
27
  apiKey: process.env.ERIC_API_KEY!,
29
28
  client: "your-app-id",
30
29
  });
31
- ```
32
-
33
- API keys are scoped and governed server-side.
34
- Keys should be treated as secrets and stored securely.
35
-
36
- ---
37
30
 
38
- ## Security Notice
31
+ const result = await eric.decide({
32
+ text: "Summarize the provided patient record",
33
+ requestType: "clinicalSummary",
34
+ });
39
35
 
40
- This SDK enforces server-side policy and execution controls.
36
+ // result.flow — resolved capability
37
+ // result.type — "structured" | "text"
38
+ // result.data — schema-validated output
39
+ ```
41
40
 
42
- API keys must be stored securely and never embedded in public repositories.
41
+ API keys are scoped and governed server-side. Never embed them in client-side code or public repositories.
43
42
 
44
43
  ---
45
44
 
46
- ## Usage
45
+ ## How it works
47
46
 
48
- ### Policy-Governed Execution
47
+ Your application calls `decide()`. Eric handles the rest:
49
48
 
50
- All interactions with Eric are routed through `decide()`.
49
+ 1. **Intent classification** — the request is classified before any routing occurs
50
+ 2. **Policy gate** — declared policy is evaluated in code, not in prompts
51
+ 3. **Capability routing** — the request is routed deterministically to a registered capability
52
+ 4. **Output validation** — the response is validated against a typed schema before it is returned
53
+ 5. **Audit log** — every execution is recorded at the moment it occurs, immutably
51
54
 
52
- Eric evaluates each request against policy, routing constraints, and execution bounds before selecting and invoking an approved capability.
53
-
54
- ```ts
55
- const result = await eric.decide({
56
- text: "summarize the provided content",
57
- requestType: "summary",
58
- });
59
- ```
55
+ If any check fails, execution stops. No fallbacks. No silent substitutions. No model is invoked.
60
56
 
61
57
  ---
62
58
 
63
- ### Optional Execution Bounds
59
+ ## Restricting execution to specific capabilities
64
60
 
65
- You may optionally restrict which capabilities are eligible for execution.
61
+ Use `allowedFlows` to restrict which capabilities are eligible for a given request.
66
62
 
67
63
  ```ts
68
64
  await eric.decide({
@@ -73,36 +69,45 @@ await eric.decide({
73
69
 
74
70
  When `allowedFlows` is provided:
75
71
 
76
- - Only capabilities in the allowed set are eligible for execution.
77
- - If resolution falls outside the allowed set, execution is denied.
78
- - No fallback or automatic substitution occurs.
72
+ - Only capabilities in the allowed set are eligible
73
+ - If no match is found, execution is denied and logged
74
+ - No fallback or automatic substitution occurs
75
+
76
+ This is equivalent to registering a capability restriction at the request level. For deployment-level restrictions, capability registration is handled during onboarding.
79
77
 
80
78
  ---
81
79
 
82
- ## Response Shape
80
+ ## Response shape
83
81
 
84
82
  ```ts
85
83
  {
86
- flow: string; // resolved capability
87
- type: "structured" | "text"; // output format classification
88
- data: unknown; // structured object or text result
84
+ flow: string; // resolved capability name
85
+ type: "structured" | "text"; // output format
86
+ data: unknown; // schema-validated output
89
87
  }
90
-
91
88
  ```
92
89
 
93
- All responses conform to pre-approved output contracts.
90
+ All responses conform to pre-approved output contracts defined at the capability level. Every field is guaranteed to be present according to the executed capability's schema.
94
91
 
95
- All fields are guaranteed to be present according to the executed capability’s contract.
92
+ ---
93
+
94
+ ## Security
95
+
96
+ - Policy is enforced server-side. The SDK cannot bypass or override execution controls.
97
+ - API keys are scoped per client and governed server-side.
98
+ - All executions — including blocked ones — are logged with a structured, timestamped, attributable record.
99
+ - Customer data is not used to train third-party models.
100
+ - BYOK (Bring Your Own Key) is supported for model providers. See onboarding documentation.
96
101
 
97
102
  ---
98
103
 
99
- ## Design Principles
104
+ ## Design principles
100
105
 
101
- * **Policy-first execution** — no direct or bypassed calls
102
- * **Deterministic behavior** — predictable outputs by design
103
- * **Auditability** — every decision and execution is logged
104
- * **Infrastructure-grade** — built for production systems, not chatbots
105
- * **Intent-based API** — clients describe what they want, not what to run
106
+ - **Policy-first** — no direct model calls, no bypassed executions
107
+ - **Deterministic** — the same request under the same policy produces the same routing decision
108
+ - **Auditable** — every decision is logged at execution time, not reconstructed after
109
+ - **Infrastructure-grade** — built for regulated production systems, not prototypes
110
+ - **Intent-based** — clients describe what they want; the control plane decides what runs
106
111
 
107
112
  ---
108
113
 
@@ -110,7 +115,7 @@ All fields are guaranteed to be present according to the executed capability’s
110
115
 
111
116
  The Eric SDK follows semantic versioning.
112
117
 
113
- Breaking changes reflect deliberate enforcement of governance and safety guarantees.
118
+ Breaking changes reflect deliberate updates to governance and safety guarantees, not implementation convenience.
114
119
 
115
120
  Pre-1.0 versions were experimental and are not supported.
116
121
 
@@ -120,7 +125,4 @@ See `CHANGELOG.md` for details.
120
125
 
121
126
  ## Support
122
127
 
123
- For access, onboarding, or documentation:
124
- [https://ericaicontrol.dev](https://ericaicontrol.dev)
125
-
126
-
128
+ For access, onboarding, or documentation: [https://ericaicontrol.dev](https://ericaicontrol.dev)
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "eric-sdk",
3
- "version": "0.1.5",
3
+ "version": "0.1.7",
4
4
  "description": "Official SDK for enforcing policy-governed AI execution using the Eric AI governance layer",
5
5
  "author": "Rod Bridges",
6
6
  "license": "MIT",
@@ -31,5 +31,12 @@
31
31
  "tsup": "^8.5.1",
32
32
  "typescript": "^5.9.3"
33
33
  },
34
- "homepage": "https://ericaicontrol.dev"
34
+ "homepage": "https://github.com/eric-ai-control/eric-sdk#readme",
35
+ "repository": {
36
+ "type": "git",
37
+ "url": "https://github.com/eric-ai-control/eric-sdk.git"
38
+ },
39
+ "bugs": {
40
+ "url": "https://github.com/eric-ai-control/eric-sdk/issues"
41
+ }
35
42
  }