@homericintelligence/athena-opencode 0.5.0 → 0.5.2

package/skills/_support/docs/principles/details/p045-compensation-where-atomicity-is-impossible.md

@@ -0,0 +1,163 @@
+# P045 — Compensation Where Atomicity Is Impossible
+
+## Definition
+
+If an operation uses different systems or cannot complete in one safe transaction, record each
+completed step. Record its recovery data.
+
+If forward work cannot continue, use domain-specific compensation until the system has a
+specified correct state. Use idempotent forward steps. Each compensation step must be a safe step,
+a resumable step, and an idempotent step. Find irreversible effects.
+
+**Aliases:** compensating transaction, saga recovery, semantic undo
+
+## Provenance
+
+**Classification:** established principle.
+
+Garcia-Molina and Salem wrote the 1987 paper that gives the saga model for long-duration
+transactions. Compensation also occurs in other workflow practices. Not all compensation workflows are formal sagas.
+
+## Decision rule
+
+When a supported atomic boundary safely contains the operation, use it. If no boundary can contain
+the operation, use durable forward, compensation, reconciliation, and manual recovery paths.
+Before the first side effect, record these paths.
+
+## How to apply
+
+- Model the workflow as named steps with durable status, correlation, and ownership.
+- Record the success criteria, idempotency key, compensation step, and retry policy for each step.
+- Before or with each effect, record sufficient context. This context must contain data for recovery
+  after a process failure or a response that the system did not receive.
+- Use business invariants to set the compensation sequence. Many workflows use the opposite
+  sequence. Some workflows use a different sequence.
+- When the system does compensation again, use a safe compensation step that is also a resumable
+  step. Record an observable result.
+- Find each irreversible point. After validation and reversible work, do irreversible steps.
+- Escalate compensation that is not clear or that fails. Include state information and a supported
+  manual procedure.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Record workflow context"] --> B["Do one idempotent forward step"]
+    B --> C["Record the completed step"]
+    C --> D{"Did the workflow complete all forward steps?"}
+    D -- Yes --> E["Record success"]
+    D -- No --> F{"Can forward work continue?"}
+    F -- Yes --> B
+    F -- No --> G["Select compensation from durable state"]
+    G --> H["Do idempotent compensation"]
+    H --> I{"Did compensation succeed?"}
+    I -- Yes --> J["Record a correct business-equivalent state"]
+    I -- No --> K["Record recovery-required state and error context"]
+```
+
+## Language examples
+
+The examples use equivalent confirmation, failure, cancellation, and recovery-required outcomes.
+
+### Python
+
+```python
+def book_trip(workflow) -> Outcome:
+    flight = workflow.step("flight", reserve_flight, cancel_flight)
+    if flight.is_error:
+        return Outcome.failed(flight.error)
+    hotel = workflow.step("hotel", reserve_hotel, cancel_hotel)
+    if not hotel.is_error:
+        return Outcome.confirmed()
+    compensation = workflow.compensate()
+    if compensation.is_error:
+        context = workflow.recovery_context()
+        return Outcome.recovery_required(hotel.error, compensation.error, context)
+    return Outcome.canceled(hotel.error)
+```
+
+### Rust
+
+```rust
+fn book_trip(workflow: &mut Workflow) -> Outcome {
+    let flight = workflow.step("flight", reserve_flight, cancel_flight);
+    if let Err(error) = flight {
+        return Outcome::failed(error);
+    }
+    let hotel = workflow.step("hotel", reserve_hotel, cancel_hotel);
+    let Err(original) = hotel else { return Outcome::confirmed() };
+    match workflow.compensate() {
+        Ok(()) => Outcome::canceled(original),
+        Err(error) => Outcome::recovery_required(original, error, workflow.recovery_context()),
+    }
+}
+```
+
+## Boundaries and tensions
+
+After compensation, the state can be different from the previous state. Concurrent work can cause
+an incorrect state before compensation. The correct result is a specified business-equivalent state.
+
+For example, a refund does not remove the historical charge from records.
+
+When [P044](p044-atomicity-where-possible.md) gives a supported transaction with less complexity,
+do not use compensation. If effects operate independently, do not identify them as one atomic operation.
+
+Each retry must satisfy [P037](p037-idempotency-before-retry.md). Each between-step workflow state
+must satisfy [P033](p033-state-safe-failure-semantics.md).
+
+## Examples
+
+### Positive application
+
+A travel workflow records flight and hotel reservations as two durable steps. The hotel
+reservation fails, and there is no approved alternative.
+
+The workflow sends idempotent cancellation commands for completed reservations. It records each
+compensation result for resumption.
+
+### Misuse or counterexample
+
+A workflow calls three services. After the third call fails, it sends non-durable “undo” calls from
+memory. After a process failure, the workflow has no completed-step record.
+
+More than one compensation call can cause new side effects.
+
+### Athena or agent workflow
+
+Before a multistep public workflow, Athena records reversible steps and steps with specified
+approval requirements. If a step fails after approved effects occur, Athena records completed effects.
+
+It uses only approved compensation that it specified before failure. It does not add a destructive
+cleanup step during the failure.
+
+## Related principles
+
+- [P033 — State-Safe Failure Semantics](p033-state-safe-failure-semantics.md)
+- [P037 — Idempotency Before Retry](p037-idempotency-before-retry.md)
+- [P044 — Atomicity Where Possible](p044-atomicity-where-possible.md)
+- [P046 — Resumability](p046-resumability.md)
+
+## References
+
+### Source information
+
+- [Garcia-Molina and Salem, “Sagas” (1987)](https://doi.org/10.1145/38714.38742)
+  — a paper that models a long-duration transaction as a sequence. Compensation transactions
+  repair execution of only some steps.
+
+### Applicable information
+
+- [Microsoft Azure, Compensating Transaction pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)
+  — applicable guidance for durable completed-step data, application-specific reversal, idempotent
+  compensation, concurrency, and irreversible points.
+- [AWS Prescriptive Guidance, Saga patterns](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-patterns.html)
+  — applicable guidance for forward recovery, recovery in the opposite sequence, choreography,
+  and orchestration.
+
+### More information
+
+- [Microsoft Azure, Design for self-healing](https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/self-healing)
+  — connects compensation with checkpoints, recovery, and resumable long-duration work.
+
+[Back to the engineering principles catalog](../README.md#p045)

package/skills/_support/docs/principles/details/p046-resumability.md

@@ -0,0 +1,138 @@
+# P046 — Resumability
+
+## Definition
+
+Resumability lets an interrupted long operation continue from durable, verified progress. The saved
+checkpoint records committed work, uncommitted work, and work with an uncertain result.
+
+**Aliases:** checkpoint/restart, durable progress, restartable workflow.
+
+## Provenance
+
+**Classification:** established principle.
+
+Engineers applied checkpoint and restart methods before workflow engines. Subsequent systems applied
+these methods to durable application milestones and operation resources, not only process state.
+No one source gives the full principle.
+
+## Decision rule
+
+If an interruption can occur, examine restart cost and safety. If restart has high cost or is not
+safe, record progress at correct recovery boundaries. If token data does not agree with the operation
+identity or position is not in range, reject the resume token. If token data agrees with the
+operation identity and position is in range, accept the token. Do not let completed work cause
+effects again.
+
+## How to apply
+
+- Give the operation a stable identity. Classify terminal, retryable, and indeterminate states.
+- After the related state transition has a durable commit, save a checkpoint.
+- Record version, input, and owner data that shows stale or incompatible checkpoints.
+- Each resumed step must be idempotent. If a step is not idempotent, deduplicate it or reconcile it
+  with authoritative state.
+- Give progress and failure reports. Record checkpoint retention and removal rules.
+- Do tests before, during, and after each external effect.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Receive operation and checkpoint"] --> B{"Is a checkpoint available?"}
+    B -- "No" --> C["Start from a safe initial state"]
+    B -- "Yes" --> D{"Operation identity correct and position in range?"}
+    D -- "No" --> E["Reject the resume request"]
+    D -- "Yes" --> F["Reconcile the last recorded effect"]
+    C --> G["Do the next idempotent step"]
+    F --> G
+    G --> H["Commit the state transition"]
+    H --> I["Save the next checkpoint"]
+```
+
+## Language examples
+
+The two examples bind checkpoints to operation, input, owner, and schema identity, apply each batch
+one time, and save only committed progress.
+
+### Python
+
+```python
+def resume(checkpoint: Checkpoint | None, batches, operation):
+    identity = (operation.id, operation.input_digest, operation.owner_id, operation.schema_version)
+    start = verify_checkpoint(checkpoint, identity, len(batches))
+    for position, batch in enumerate(batches[start:], start=start):
+        apply_once(batch.id, batch.items)
+        save_checkpoint(identity, position + 1)
+```
+
+### Rust
+
+```rust
+fn resume(checkpoint: Option<&Checkpoint>, batches: &[Batch], operation: &Operation) -> Result<(), Error> {
+    let identity = ResumeIdentity::new(
+        &operation.id, &operation.input_digest, &operation.owner_id, operation.schema_version);
+    let start = verify_checkpoint(checkpoint, &identity, batches.len())?;
+    for (offset, batch) in batches[start..].iter().enumerate() {
+        apply_once(batch.id, &batch.items)?;
+        save_checkpoint(&identity, start + offset + 1)?;
+    }
+    Ok(())
+}
+```
+
+## Boundaries and tensions
+
+Resumability is not an automatic retry without a check. A checkpoint can keep corrupt or obsolete
+state. Before the system accepts a checkpoint, validate checkpoint integrity and compatibility.
+
+A restart can be correct for a short, low-cost operation without side effects. If one boundary can
+contain the operation, use an atomic transaction. Distributed work can make compensation necessary.
+
+A resumed operation must use authority that applies at resume time. It must not use expired
+credentials or approvals again.
+
+## Examples
+
+### Positive
+
+A migration records the committed position, schema version, input digest, and operation ID. After
+an interruption, it verifies those fields and reconciles the batch at the saved position. It then
+continues at the saved position.
+
+### Misuse
+
+A worker stores only `step = 4`. It stops after a payment but before the next checkpoint. A restart
+sends the payment again because the checkpoint does not record the uncertain effect.
+
+### Athena and agent workflows
+
+A coordinator records completed task IDs, accepted artifact hashes, and dependencies that are not
+satisfied. After a host interruption, it validates the checkout again. It resumes only tasks that
+are not completed.
+
+## Related principles
+
+- [P044 — Atomicity Where Possible](p044-atomicity-where-possible.md)
+- [P045 — Compensation Where Atomicity Is Impossible](p045-compensation-where-atomicity-is-impossible.md)
+- [P047 — Observability Is Part of Correctness](p047-observability-is-part-of-correctness.md)
+- [P053 — Validate at Trust Boundaries](p053-validate-at-trust-boundaries.md)
+
+## References
+
+### Source information
+
+- [USENIX: *Libckpt: Transparent Checkpointing under UNIX* (1995)](https://www.usenix.org/conference/usenix-1995-technical-conference/libckpt-transparent-checkpointing-under-unix)
+  gives information about checkpoint and restart methods for interrupted long computations.
+
+### Applicable information
+
+- [Google AIP-151: Long-running operations](https://google.aip.dev/151) gives a durable operation
+  resource that lets clients monitor progress and retrieve a result.
+- [AWS Step Functions redrive guidance](https://docs.aws.amazon.com/step-functions/latest/dg/redrive-executions.html)
+  gives information about restart from workflow steps with failures and retention of results.
+
+### More information
+
+- [USENIX: *Transparent Checkpoint-Restart of Multiple Processes*](https://www.usenix.org/legacy/event/usenix07/tech/full_papers/laadan/laadan_html/paper.html)
+  gives consistency requirements for checkpoints in cooperative processes with shared state.
+
+[Back to the principles catalog](../README.md#p046)

package/skills/_support/docs/principles/details/p047-observability-is-part-of-correctness.md

@@ -0,0 +1,134 @@
+# P047 — Observability Is Part of Correctness
+
+## Definition
+
+Observability lets operators use structured logs, metrics, and traces to find system state and
+operation outcomes. When operators must find failure, find completed work and work not completed,
+and restore service safely, observability is part of correctness.
+
+**Aliases:** operational diagnosability, production visibility, telemetry-by-design.
+
+## Provenance
+
+**Classification:** Athena synthesis.
+
+Observability practice is evidence for this synthesis. Distributed tracing and
+production monitoring have long histories. No one source gives this Athena rule.
+
+## Decision rule
+
+For important behavior, emit sufficient correlated and non-sensitive evidence that shows the event,
+location, time, operation, and cause. If operators cannot find an important failure in the specified
+response period, the operational contract does not have sufficient information.
+
+## How to apply
+
+- Select signals from user outcomes and operational questions. Do not select signals only
+  because data is available.
+- Use stable request, trace, or operation identifiers to correlate work at all boundaries.
+- Record structured status, reason, duration, and dependency context at the responsible boundary.
+- Use metrics for trends and alerting, traces for causal paths, and logs for discrete evidence.
+- Before production starts, set data retention, sampling, cardinality, access, and redaction
+  policies.
+- Do telemetry tests for important success, failure, cancellation, completed work, and work not
+  completed.
+
+## Diagram
+
+```mermaid
+flowchart LR
+    A["Important operation"] --> B["Emit correlated safe signals"]
+    B --> C["Logs record discrete evidence"]
+    B --> D["Metrics show trends and alerts"]
+    B --> E["Traces show causal paths"]
+    C --> F["Find the outcome and cause"]
+    D --> F
+    E --> F
+```
+
+## Language examples
+
+The two examples record a duration metric and a structured outcome event that contains the request
+identifier.
+
+### Python
+
+```python
+def transfer(request_id, amount):
+    started = clock.now()
+    result = ledger.try_transfer(amount)
+    metrics.observe("transfer_ms", clock.now() - started)
+    log.info("transfer_complete", request_id=request_id, status=result.status)
+    return result
+```
+
+### Rust
+
+```rust
+fn transfer(request_id: &str, amount: Money) -> Result<Receipt, Error> {
+    let started = clock::now();
+    let result = ledger::try_transfer(amount);
+    let status = match &result {
+        Ok(_) => "ok",
+        Err(_) => "error",
+    };
+    metrics::observe("transfer_ms", clock::now() - started);
+    log::info("transfer_complete", request_id, status);
+    result
+}
+```
+
+## Boundaries and tensions
+
+Telemetry cannot correct incorrect behavior. High signal volume is not observability. A large signal
+volume or high cardinality can prevent incident detection and can consume all resources.
+
+Logs are a data store and an attack surface. Do not emit secrets for diagnosis. Use safe identifiers
+that do not contain raw customer content. Samples must keep evidence for important security and
+failure events.
+
+## Examples
+
+### Positive
+
+One trace ID identifies a request in all services. Each boundary records a structured outcome and
+latency. Dashboards report errors that users see. Traces show the dependency with the failure.
+
+### Misuse
+
+A service writes free-form debug messages that contain access tokens. It has no request correlation,
+outcome metric, or alert. The messages are not safe and cannot give a clear diagnosis.
+
+### Athena and agent workflows
+
+A delegated task reports its task ID, bounded outcome, validation evidence, and specified failure
+reason.
+The report does not contain credentials or file content that does not apply. The coordinator can
+find a completed task, a timed-out task, or a task that stopped before all work ended.
+
+## Related principles
+
+- [P046 — Resumability](p046-resumability.md)
+- [P053 — Validate at Trust Boundaries](p053-validate-at-trust-boundaries.md)
+- [P056 — Secrets Stay Out of Code and Context](p056-secrets-stay-out-of-code-and-context.md)
+
+## References
+
+### Source information
+
+- [Google Research: *Dapper, a Large-Scale Distributed Systems Tracing Infrastructure*](https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/)
+  gives an important production trace design and its diagnostic goals.
+
+### Applicable information
+
+- [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/)
+  gives information about logs, metrics, traces, correlation, and service reliability.
+- [OpenTelemetry Specification 1.60.0](https://opentelemetry.io/docs/specs/otel/) gives
+  vendor-neutral telemetry and instrumentation contracts.
+
+### More information
+
+- [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+  gives information about event design, sanitization, sensitive data exclusion, and log protection.
+
+[Back to the principles catalog](../README.md#p047)

package/skills/_support/docs/principles/details/p048-secure-by-design.md

@@ -0,0 +1,132 @@
+# P048 — Secure by Design
+
+## Definition
+
+Secure by Design makes security a requirement for architecture, implementation, delivery, and
+operation from the start. Each design includes controls for threats to trust boundaries, data flows,
+privileges, dependencies, and execution capabilities.
+
+**Aliases:** security by design, built-in security, security during the full life cycle.
+
+## Provenance
+
+**Classification:** established principle.
+
+Security design principles have a long history. Standards organizations and public security agencies
+give the *Secure by Design* formulation in software life cycle guidance.
+
+## Decision rule
+
+Before a capability changes trust, record the assets, actors, and boundaries. Then find the threats,
+failure modes, and necessary controls. Before the cost of changes is high, make the controls part of
+the architecture and acceptance criteria.
+
+## How to apply
+
+- Classify protected assets. Map each new or changed trust boundary and data flow.
+- Model threats to entry points, identities, privileges, dependencies, and abuse cases.
+- Select safe contracts, isolation, validation, and authorization before implementation details.
+- Include security tests, evidence, operational data, update paths, and incident response in
+  delivery.
+- If permissions, integrations, dependencies, or operational assumptions change, do the threat
+  model again.
+- Give the product owner responsibility for security outcomes. Do not give all risk to users.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["New capability"] --> B["Record assets and actors"]
+    B --> C["Map trust boundaries and find threats"]
+    C --> D["Select architecture controls"]
+    D --> E["Give security acceptance criteria"]
+    E --> F["Implement and verify"]
+    F --> G{"Threat model changed?"}
+    G -- "Yes" --> B
+    G -- "No" --> H["Operate with evidence"]
+```
+
+## Language examples
+
+The two examples verify a signature for the canonical body and nonce before replay checks,
+validation, authorization, and queue insertion.
+
+### Python
+
+```python
+def accept_webhook(request):
+    signed = canonicalize(request.body, request.nonce)
+    sender = verify_signature(request.signature, signed)
+    reject_replay(request.nonce)
+    event = validate_payload(request.body)
+    authorize(sender, event.tenant)
+    queue.put(AuthenticatedEvent(sender, event))
+```
+
+### Rust
+
+```rust
+fn accept_webhook(request: Request) -> Result<(), Error> {
+    let signed = canonicalize(&request.body, &request.nonce);
+    let sender = verify_signature(&request.signature, &signed)?;
+    reject_replay(&request.nonce)?;
+    let event = validate_payload(&request.body)?;
+    authorize(&sender, &event.tenant)?;
+    queue::put(AuthenticatedEvent::new(sender, event))
+}
+```
+
+## Boundaries and tensions
+
+Secure by Design does not mean that all locations must have maximum controls. Controls must be
+correct for the assets, threats, and impact. Controls must not prevent necessary operations.
+
+Compliance evidence cannot replace threat analysis. Penetration tests after implementation can find
+security defects. They cannot repair a trust model that is not safe at low cost. This principle
+applies to the full life cycle. Secure by Default applies to the initial product configuration.
+
+## Examples
+
+### Positive
+
+Before implementation, a new webhook integration has requirements for authenticated senders,
+replay resistance, payload limits, secret rotation, failure control, and audit events.
+
+### Misuse
+
+A team ships an administrative API with more credentials than necessary. After customers start to
+use the API, the team plans authorization and audit logs.
+
+### Athena and agent workflows
+
+Before a new tool becomes available, an Athena workflow records the data, calls, authority, output
+checks, and failure reports for that tool.
+
+## Related principles
+
+- [P049 — Secure by Default](p049-secure-by-default.md)
+- [P050 — Least Privilege](p050-least-privilege.md)
+- [P053 — Validate at Trust Boundaries](p053-validate-at-trust-boundaries.md)
+- [P054 — Defense in Depth](p054-defense-in-depth.md)
+
+## References
+
+### Source information
+
+- [Saltzer and Schroeder, *The Protection of Information in Computer Systems*](https://doi.org/10.1109/PROC.1975.9939)
+  is a primary source for secure system design principles. It was published before the *Secure by
+  Design* term.
+
+### Applicable information
+
+- [CISA, *Shifting the Balance of Cybersecurity Risk*](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf)
+  gives Secure by Design and Secure by Default expectations for software producers.
+- [NIST SP 800-218, SSDF Version 1.1](https://doi.org/10.6028/NIST.SP.800-218) gives secure
+  practices during the full life cycle for software development.
+
+### More information
+
+- [CISA Secure by Demand Guide](https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf)
+  gives software customers questions to examine producer security practices.
+
+[Back to the principles catalog](../README.md#p048)

package/skills/_support/docs/principles/details/p049-secure-by-default.md

@@ -0,0 +1,126 @@
+# P049 — Secure by Default
+
+## Definition
+
+Secure by Default means that the initial configuration and easiest supported path give sufficient
+protection. Users can use necessary controls without an activation step. A user must make a clear
+selection to use a weaker configuration.
+
+**Aliases:** safe defaults, security out of the box, default-deny configuration.
+
+## Provenance
+
+**Classification:** established principle.
+
+Fail-safe defaults came before this principle. CISA guidance gives a product-level formulation. The
+two formulations are related, but they are different.
+
+## Decision rule
+
+Select defaults that decrease possible damage for a new installation. Apply these defaults to
+authentication, authorization, network exposure, data protection, and telemetry. If an insecure
+compatibility mode is necessary, give clear risk information and a different activation step.
+
+## How to apply
+
+- After a user or policy records permissions, grant the permissions. Do not ship access that users
+  must remove.
+- Disable endpoints, accounts, tools, and network listeners that are not necessary.
+- Use secure protocol, cryptographic, privacy, and update settings as defaults.
+- Make high-risk configuration changes clear, auditable, and reversible.
+- Do tests with a clean installation and the primary initial path. Do not do tests only with an
+  expert configuration.
+- Give migration guidance for stronger defaults in installed systems.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Clean installation"] --> B["Apply secure initial configuration"]
+    B --> C["Limit exposure and use identity checks"]
+    C --> D{"User selects a weaker mode?"}
+    D -- "No" --> E["Keep secure configuration"]
+    D -- "Yes" --> F["Show risk and get clear user consent"]
+    F --> G["Record the configuration change"]
+```
+
+## Language examples
+
+The two examples default to local access, authentication on, and no administrative interface.
+
+### Python
+
+```python
+@dataclass
+class Config:
+    bind: str = "127.0.0.1"
+    require_auth: bool = True
+    admin_enabled: bool = False
+```
+
+### Rust
+
+```rust
+impl Default for Config {
+    fn default() -> Self {
+        Self {
+            bind: "127.0.0.1".into(),
+            require_auth: true,
+            admin_enabled: false,
+        }
+    }
+}
+```
+
+## Boundaries and tensions
+
+A default must work in its specified context. A control that all users disable does not give
+sufficient security.
+
+Deployed systems can have compatibility constraints. Those constraints do not make insecure
+defaults correct for new deployments. Secure by Default applies to the initial configuration. Fail
+Closed applies to a runtime security decision that is not completed.
+
+## Examples
+
+### Positive
+
+A service listens only on loopback and uses authentication. It creates no shared default
+password. An operator must select and configure administrative access.
+
+### Misuse
+
+A dashboard binds to a public interface with anonymous administrator access. The documentation
+tells users to add authentication subsequently.
+
+### Athena and agent workflows
+
+A new tool starts with read-only repository scope. It gets write access only for a task that grants
+that access. Installation does not expand agent authority.
+
+## Related principles
+
+- [P048 — Secure by Design](p048-secure-by-design.md)
+- [P050 — Least Privilege](p050-least-privilege.md)
+- [P051 — Complete Mediation](p051-complete-mediation.md)
+- [P054 — Defense in Depth](p054-defense-in-depth.md)
+
+## References
+
+### Source information
+
+- [Saltzer and Schroeder, *The Protection of Information in Computer Systems*](https://doi.org/10.1109/PROC.1975.9939)
+  gives information about access decisions that use permission, not exclusion. This fail-safe
+  default is a historical source for this product-configuration principle.
+
+### Applicable information
+
+- [CISA, *Shifting the Balance of Cybersecurity Risk*](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf)
+  makes security part of the default product experience and gives producers responsibility.
+
+### More information
+
+- [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
+  uses denial as the default authorization policy and gives authorization-policy tests.
+
+[Back to the principles catalog](../README.md#p049)