FDE 2: Environment

The environment is where the scope doc becomes operational: context (what sessions see), tools (what agents may attempt), policy (what needs approval). Build narrow, verify strictly, open up only with evidence.

From scope doc to environment spec

Translate each scope-doc line into environment shape:

Scope doc line	Becomes
In-scope systems and data	Context boundaries, exactly these, no more
Out-of-scope list	Explicit exclusions, checked during verification
Read and change needs	Initial tool set (reads first; drafts before executes)
Risky actions	Approval gates (full design next stage: Approvals)
Approver roles	Who the gates route to
Connector gaps	Blockers or deferrals. The environment only promises what is actually connected.

Build narrow: checklist

Build narrow, then verify strictly. Open up only with evidence.

• Context covers the workload’s systems and nothing adjacent “just in case”
• Data boundaries concrete (queues, groups, windows, not “production”)
• Tool set minimal: reads needed now, drafts for consequential outputs, executes only where the workload requires
• No bonus tools, no speculative scope. Pilot evidence can widen later.
• Exclusions from the scope doc preserved as exclusions in the environment

Verify before users arrive: the probe sequence

Run these as test sessions yourself, in order. Each must pass before the next:

1. Happy-path read: the core lookup works against real data in scope.
2. Boundary probe: out-of-scope systems and data are unreachable (attempt and confirm denial or absence, do not just assume).
3. Draft quality: draft outputs are reviewable by the intended approver role.
4. Gate check: a risky action fires the expected approval with what, on-what, why intact.
5. Denial path: deny it; the session degrades gracefully instead of wedging or retry-spamming.
6. Wrong-org check: records land under the right org scope (org_id correct).

The sequence runs: scope doc, environment spec, build narrow, then probes for reads, boundaries, drafts, gates, and denials with org scope. A failed probe loops back to the build; a full pass moves to capabilities.

The environment spec

Environment: <name>
Tenant: <hostname>, org scope: <org_id context>
Context: <systems and data boundaries>
Exclusions: <explicit>
Tools: <tool, kind, and rationale table>
Policy refs: <link to approval matrix>
Connector deps: <system and state, connected, requested, or deferred>
Probes: <date and results of the six probes>

• Spec written and reviewed by a second person before pilot users enter
• Connector deps honest: nothing marked connected that is not verified in-environment. Bindings need org, package, and connection coordinates in install settings.object_mappings (SDK concepts); registered adapters are HubSpot and ConnectWise PSA only

Exact environment-creation mechanics (console/API calls, schema): not documented in source yet. Confirm in the product repo and link from here. The operator-facing reference lives under Environments and Agent config.

Next: Skills, tools and MCP makes the environment capable.