> For the complete documentation index, see [llms.txt](https://wiki.fridays.bot/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.fridays.bot/documentation/white-paper/references.md).

# References

References for *Fridays: An Approval-Gated AI Orchestration Layer for the SMB Back Office* (Whitepaper v1.0). Grouped by theme; each entry notes the section it supports and why. Legal and standards sources were re-verified on **2 July 2026** — regulatory status changes quickly, so treat dates as of that check. Foundational specifications (RFCs, NIST, ISO, classic papers) are cited by their stable identifiers.

***

### 1. AI regulation & governance

*Supports §6 (Approval Model), §12 (Compliance & Governance), and the AI Governance companion.*

**European Parliament and Council.** *Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act).* OJ, 12 July 2024. <https://eur-lex.europa.eu/eli/reg/2024/1689/oj> → Art. 50 transparency obligations apply from **2 August 2026** (Art. 113); penalties reach **€15M or 3% of worldwide annual turnover** (Art. 99). The whitepaper's approval gate falls under the assistive-editing / no-substantial-alteration reasoning for Art. 50(2) marking.

**European Commission.** *Digital Omnibus on AI — proposal and provisional agreement.* Proposal 19 Nov 2025; provisional political agreement 6–7 May 2026; endorsed by the European Parliament 16 June 2026. <https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai> → As of the verification date the Omnibus is **not yet formally adopted or published in the Official Journal**, so the original text of Reg (EU) 2024/1689 remains controlling. Its main effect for Fridays: Art. 50(2) machine-readable marking gets a grace period to **2 December 2026** for systems already on the market before 2 Aug 2026.

**European Commission.** *Draft Guidelines on the implementation of the transparency obligations under Article 50 of the AI Act* (8 May 2026) and *Code of Practice on marking and labelling of AI-generated content* (10 June 2026). → The Commission's own interpretation of who must disclose chatbots and mark synthetic content; the reference point for §12's marking analysis.

**European Parliament and Council.** *Regulation (EU) 2016/679 (General Data Protection Regulation).* OJ, 4 May 2016. <https://eur-lex.europa.eu/eli/reg/2016/679/oj> → Art. 22 (automated individual decision-making) is the legal hook the approval gate is designed to satisfy: a human decision, not solely automated processing.

**Article 29 Data Protection Working Party.** *Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679.* WP251rev.01, adopted 3 Oct 2017, revised 6 Feb 2018 (endorsed by the EDPB). → Defines "meaningful human involvement" — the standard §6 argues the one-tap approval meets (a human who can and does override, not a rubber stamp).

**Colorado General Assembly.** *SB 24-205, Consumer Protections for Artificial Intelligence (Colorado AI Act).* Signed 17 May 2024. <https://leg.colorado.gov/bills/sb24-205> — *SB 25B-004* (delayed effect to 30 June 2026) — *SB 26-189, Automated Decision-Making Technology Act*, signed 14 May 2026, effective **1 January 2027**, which repealed and reenacted SB 24-205. <https://leg.colorado.gov/bills/sb26-189> → The duty-of-care / bias-audit regime never took effect; SB 26-189 substitutes disclosure + meaningful human review. Its "consequential decision" scope (education, employment, housing, finance, insurance, health care, essential government services) and its exclusions for fraud/identity/security uses are why back-office automation likely sits outside the core obligations — analyzed in §12.

**California.** *California Consumer Privacy Act (Cal. Civ. Code §1798.100 et seq.), as amended by the CPRA*; and California Privacy Protection Agency, *Regulations on Automated Decisionmaking Technology (ADMT)* (finalized 2025). <https://cppa.ca.gov> → Governs consumer data rights and ADMT notice/opt-out for California customers; supports §9 and §12.

**U.S. Federal Trade Commission.** *Section 5, FTC Act (15 U.S.C. §45)*; *Operation AI Comply* (25 Sept 2024); business guidance *"Keep your AI claims in check"* (27 Feb 2023). <https://www.ftc.gov> → Automation and efficacy claims must be substantiated; this is why §11's efficacy claims are gated on the (still-to-be-built) evaluation harness rather than asserted.

**NIST.** *Artificial Intelligence Risk Management Framework (AI RMF 1.0),* NIST AI 100-1, Jan 2023; and *Generative AI Profile,* NIST AI 600-1, July 2024. <https://www.nist.gov/itl/ai-risk-management-framework> → The voluntary framework §12 maps controls to for a defensible governance posture across jurisdictions.

***

### 2. Prompt injection & agent security

*Supports §5 (Agent Orchestration) and §8 (Security Architecture).*

**OWASP.** *OWASP Top 10 for LLM Applications (2025).* <https://genai.owasp.org/llm-top-10/> → **LLM01 Prompt Injection** (ranked #1 for the second consecutive edition), **LLM06 Excessive Agency**, and **LLM10 Unbounded Consumption** are the exact failure classes §8 and §5 counter — via read/act separation, capability scoping, and budget hard-stops respectively. OWASP's own remediation ("human-in-the-loop for high-risk actions; least-privilege tooling") is the approval-gate thesis.

**Greshake, K., et al.** *Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.* AISec @ CCS 2023. arXiv:2302.12173. → The canonical demonstration that untrusted content (email, documents, web pages) can hijack an LLM agent — the threat model §8 is built around.

**Perez, F., and Ribeiro, I.** *Ignore Previous Prompt: Attack Techniques for Language Models.* NeurIPS ML Safety Workshop, 2022. arXiv:2211.09527. → Early formalization of direct prompt injection; establishes that instructions and data share one channel.

**Debenedetti, E., et al.** *Defeating Prompt Injections by Design (CaMeL).* Google / Google DeepMind / ETH Zürich, 2025. arXiv:2503.18813. → The closest academic parallel to Fridays' architecture: extract control/data flow from the trusted query and enforce capability-based policy at tool-call time so untrusted data can never alter what executes. Cited in §5/§8 as independent validation of "put the deterministic control plane outside the model."

**Willison, S.** *The Dual LLM pattern for building AI assistants that can resist prompt injection.* April 2023. <https://simonwillison.net/2023/Apr/25/dual-llm-pattern/> → Origin of the quarantined-vs-privileged split that motivates §8's low-trust ingestion profile.

**Debenedetti, E., et al.** *AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents.* NeurIPS 2024 Datasets & Benchmarks. arXiv:2406.13352. → The kind of adversarial, task-based harness §11 argues Fridays needs for agent-behavior evaluation (distinct from code tests).

***

### 3. Agent orchestration, reasoning & tool interfaces

*Supports §3 (Integration Layer) and §5 (Agent Orchestration).*

**Yao, S., et al.** *ReAct: Synergizing Reasoning and Acting in Language Models.* ICLR 2023. arXiv:2210.03629. → Foundation for the plan-then-act loop underlying the planner/executor model in §5.

**Schick, T., et al.** *Toolformer: Language Models Can Teach Themselves to Use Tools.* NeurIPS 2023. arXiv:2302.04761. → Establishes tool-calling as a first-class model capability — the basis for connector/adapter invocation.

**Anthropic.** *Introducing the Model Context Protocol.* 25 Nov 2024. <https://modelcontextprotocol.io> → The agent-facing tool interface Fridays exposes and consumes; §3 explains why MCP connections are routed through Fridays' own gateway for metering and approval interception rather than called directly.

**JSON-RPC Working Group.** *JSON-RPC 2.0 Specification.* 2010. <https://www.jsonrpc.org/specification> → The transport for out-of-process plugin workers (stdio) described in §3.

***

### 4. Distributed systems, transactions & reliability

*Supports §5 (Orchestration), §7 (Audit & Observability), §10 (Reliability), and the Data Model / Observability companions.*

**Garcia-Molina, H., and Salem, K.** *Sagas.* ACM SIGMOD 1987, pp. 249–259. doi:10.1145/38713.38742. → The compensation-based long-running-transaction model behind §5's cross-vendor rollback (there is no two-phase commit across QuickBooks, Gmail, and a bank).

**Helland, P.** *Idempotence Is Not a Medical Condition.* ACM Queue, 2012. → Rationale for the exactly-once/idempotent ticket semantics (atomic checkout, one-retry-plus-recovery) in §5.

**Beyer, B., Jones, C., Petoff, J., and Murphy, N. R. (eds.).** *Site Reliability Engineering: How Google Runs Production Systems.* O'Reilly, 2016. <https://sre.google/sre-book/table-of-contents/> → Source for the SLI/SLO/error-budget vocabulary in §10 and the Observability companion, including why "connector liveness" should be an anti-fail-open SLO.

**Cloud Native Computing Foundation.** *OpenTelemetry Specification.* <https://opentelemetry.io/docs/specs/> → The tracing/metrics standard the Observability companion proposes for end-to-end request and cost attribution.

***

### 5. Identity, authentication & secrets

*Supports §4 (Identity, Auth & Secrets) and §8 (Security Architecture).*

**IETF.** *RFC 6749 — The OAuth 2.0 Authorization Framework* (2012); *RFC 7636 — Proof Key for Code Exchange (PKCE)* (2015); *RFC 9700 — Best Current Practice for OAuth 2.0 Security* (2025); *RFC 7519 — JSON Web Token (JWT)* (2015); *RFC 8725 — JWT Best Current Practices* (2020). <https://www.rfc-editor.org> → The connector authorization and short-lived run-token model in §4 (PKCE for public clients; JWT with audience restriction; the security BCP for refresh-token handling).

**IETF / NIST.** *RFC 2104 — HMAC* (1997); *FIPS 198-1 — The Keyed-Hash Message Authentication Code (HMAC)* (2008). → The webhook-signature scheme (HMAC-SHA256 with a replay window) in §3 and routine ingestion in §5.

**NIST.** *SP 800-38D — Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC* (2007); *SP 800-57 Part 1 Rev 5 — Recommendation for Key Management* (2020). <https://csrc.nist.gov/publications/sp> → AES-256-GCM secret encryption and the envelope/key-hierarchy discussion in §4 and §8.

**Cloud Native Computing Foundation.** *SPIFFE — Secure Production Identity Framework for Everyone,* and *SPIRE.* <https://spiffe.io> → The workload-identity model §4/§8 cite as the target (aspirational) design for per-service identity beyond static keys.

**W3C.** *Web Authentication (WebAuthn) Level 2* (W3C Recommendation, 2021); FIDO Alliance, *FIDO2.* <https://www.w3.org/TR/webauthn-2/> → The phishing-resistant MFA standard named as planned auth hardening in §4.

***

### 6. Compliance frameworks

*Supports §12 (Compliance & Governance).*

**AICPA.** *TSP Section 100 — 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022).* <https://www.aicpa-cima.com> → The SOC 2 criteria the control substrate (central authorization, audit logging, approval gates, budget enforcement, encrypted secrets) is built to satisfy — noted in §12 as planned, not yet certified.

**ISO/IEC.** *ISO/IEC 27001:2022 — Information security management systems — Requirements,* and *ISO/IEC 42001:2023 — Artificial intelligence management system.* <https://www.iso.org> → The information-security and AI-management standards §12 maps to for cross-jurisdiction governance.

***

### 7. Integration & vendor platform documentation

*Supports §3 (Integration Layer) and the Rate Limiting & Quotas companion.*

**Google.** *Google API Services User Data Policy* (including the Limited Use requirements) and *Gmail / Google Workspace APIs.* <https://developers.google.com/terms/api-services-user-data-policy> → The no-training / limited-use obligations that flow down the whole chain, cited in §9 and the Data Handling companion; plus the Gmail API surface and quota model.

**Microsoft.** *Microsoft Graph REST API and throttling guidance.* <https://learn.microsoft.com/graph/> → The Microsoft 365 connector surface and per-service throttling shapes analyzed in the Rate Limiting companion.

**Intuit.** *QuickBooks Online Accounting API and request-throttling limits.* <https://developer.intuit.com> → The accounting connector surface; Intuit throttling is flagged as a go-to-market/app-review risk in the Rate Limiting companion.

**Zoho.** *Zoho APIs.* <https://www.zoho.com/developer/> — **Stripe.** *Stripe API (idempotency keys, rate limits).* <https://stripe.com/docs/api> — **Shopify.** *Admin API.* <https://shopify.dev/docs/api> → The remaining launch/near-term connector surfaces referenced in §3.

***

### 8. Market & problem context

*Supports §1 (Introduction).*

**U.S. Small Business Administration, Office of Advocacy.** *Small Business Profiles and Frequently Asked Questions.* <https://advocacy.sba.gov> → General market context for the SMB administrative-burden framing in §1. Any specific figure used in the introduction should be pinned to a named primary source before publication rather than asserted.

***

*Companion series V1 · Fridays whitepaper · compiled 2 July 2026. Regulatory entries are informational, re-verified as of that date, and are not legal advice.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.fridays.bot/documentation/white-paper/references.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
