Read vs. write surfaces

preset AI is bi-directional infrastructure: AI tools can both read and write through MCP. Clear boundaries between the two prevent policy bypass and unsafe auto-apply behavior.

Copy link to sectionWhy this matters

Without explicit read/write boundaries:

• Policy gates can be bypassed by treating writes as routine
• Auto-apply becomes the default and drift accumulates silently
• Auditability degrades — you lose the trail of who changed what

Copy link to sectionRead surfaces

Read surfaces gather context and should be the default mode of operation.

Use for:

• Artifact discovery
• Token, preset, and pattern lookup
• Active constraint retrieval
• Health, drift, and compliance diagnostics

Properties:

• No canonical state mutation
• Low operational risk
• High frequency in normal workflows

Copy link to sectionWrite surfaces

Write surfaces can mutate system state directly or indirectly.

Use for:

• Creating or updating proposals
• Applying approved changes
• Mutating canonical artifacts

Properties:

• Governance policy applies
• Requires explicit scope and permissions
• Must be auditable

Copy link to sectionGuardrail policy

Recommended baseline for any client integrating against MCP:

1. Read-first by default
2. Write only through the propose → validate → apply lifecycle
3. Enforce approval gates in Guard and Enforce modes
4. Always log actor, scope, diff metadata, and outcome

Copy link to sectionWhen to escalate

Treat a write as elevated risk — request additional approval or surface the action to the user — when:

• The change impacts shared artifacts broadly
• Policy-critical rules are affected
• Confidence is low or validation findings are ambiguous