Externally managed fields

[zeevdr]

Description

Explore support for fields whose values are managed outside decree's scope. These fields exist in the schema but their values originate from or are synchronized with external systems. Covers read-only imports (external system is source of truth) and read/write via webhooks (decree coordinates but doesn't own the value).

Key questions

• Define ownership model: read-only (external → decree) vs read/write (bidirectional sync)
• Schema representation: how are external fields declared? (new field attribute? separate field kind?)
• Read mechanism: webhook pull? push via API? polling interval?
• Write mechanism: webhook callback when value changes in decree? event stream?
• Staleness: how to handle stale cached values? TTL? version tracking?
• Tenant scoping: external sources may serve multiple tenants — how to map?
• UI impact: how should decree-ui render externally managed fields? (read-only indicator, sync status)
• SDK impact: do SDKs need to distinguish external fields from native ones?
• Failure modes: external source unavailable — serve stale? error? default?
• Audit trail: how to attribute changes that originate externally?

Context

Related to CEL expressions (#76) and validation webhooks (#77) — these are complementary approaches. CEL handles internal validation complexity, webhooks handle external validation logic, externally managed fields handle external data ownership. This feature addresses "where does this value live?" ambiguity in multi-system architectures.

[zeevdr]

Related discovery issues: #76 (CEL expressions), #77 (validation webhooks)