Add governed reusable pipelines and triggers
This commit is contained in:
18
README.md
18
README.md
@@ -63,6 +63,24 @@ pipeline revision, and can atomically publish a complete result through
|
||||
truncated; larger asynchronous and artifact-backed execution belongs to a
|
||||
subsequent runner slice.
|
||||
|
||||
## Governed Definitions And Automation
|
||||
|
||||
Pipelines can be complete flows or reusable templates at system, tenant,
|
||||
group, or user scope. Templates never run directly. A permitted consumer
|
||||
derives a new definition that pins the source revision and content hash and
|
||||
records the effective Policy decision and ancestor limits. Inherited
|
||||
definitions remain read-only; lower scopes may narrow, but not broaden,
|
||||
execution, reuse, inheritance, or automation permissions.
|
||||
|
||||
Complete active flows support explicit user/API starts, administrative
|
||||
backfills, one-time schedules, interval schedules, and exact-match platform
|
||||
events. Trigger deliveries are durable and idempotent. They pin the pipeline
|
||||
revision and a least-privilege scope grant, then ask Access to rebuild the
|
||||
owner's current principal before every run. Revoked memberships or reduced
|
||||
permissions block the delivery before source access or output publication.
|
||||
Confidential and restricted events are not accepted through the direct
|
||||
ingress; those require Core's transactional event bridge.
|
||||
|
||||
## Development
|
||||
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user