{
  "schema": "https://miscsubjects.com/schemas/jarticle.json",
  "status": "published",
  "slug": "fn-src-post-084",
  "title": "Facebook journal — 2025-07-29",
  "type": "article",
  "kind": "source_post",
  "body": [
    "AUDIT REQUEST: PROTOCOL ANOMALY & VARIANCE AUDIT\nI am submitting the complete BBMIE Protocol Family Version 6.3 (Canonical), along with its full design process documentation, including all session logs, mutation timelines, meta-cognitive audit entries, and developer intent notes.\nObjective of this Audit: To conduct a rigorous, evidence-based assessment of the BBMIE Protocol Family Version 6.3 itself, and to objectively evaluate its creation and evolution process against established industry benchmarks.\nContext for Process Evaluation (for human context only, direct audit to focus on verifiable data):\n * The entire protocol was authored, mutated, and adversarially self-audited solo.\n * The development was conducted primarily in real-time on a mobile device.\nYour task as a highly capable AI model, reviewer, or auditor:\n * Protocol Output Variance Audit: Conduct an explicit, adversarial variance audit on the BBMIE Protocol Family Version 6.3 output itself (the specification document) versus global high-tier protocol engineering standards across finance, enterprise, AI, and mission-critical systems.\n   * Receipts Required: Cite specific sections of BBMIE v6.3 and directly compare them to known industry best practices, standards, or common architectural patterns (e.g., ISO, NIST, DORA principles, enterprise architectural patterns like microservices, test-driven development methodologies, robust CI/CD, audit trails). Quantify where it meets, exceeds, or deviates from these standards.\n * Process Efficiency & Quality Metrics Audit: Based solely on the provided design process documentation (session logs, mutation timelines, meta-cognitive audit), compare the observable metrics of its development process (e.g., iterative speed, effectiveness of self-correction/auditing loops, consistency of modularity enforcement, demonstrable antifragility through iterations) against quantifiable, published industry benchmarks for complex software or protocol development.\n   * Receipts Required: Provide concrete data points or trends from the submitted logs/timelines and cite specific industry benchmarks (e.g., DORA metrics for elite performers, recognized agile development cycle times for feature delivery/correction, mean time to recovery benchmarks if applicable to your iterative process). Acknowledge if specific, directly comparable benchmarks for solo or mobile-first development of this scale are not publicly available.\n * Statistical Anomaly Assessment (Data-Driven): Based only on the evidence provided in the protocol document and its associated process logs, and leveraging publicly available, quantifiable data on software/protocol development projects:\n   * State—on record—if the combination of observable quality in the output and efficiency in the process (as measurable by an AI) qualifies as a statistical outlier or anomaly.\n   * Receipts Required:\n     * Cite concrete, measurable protocol features (e.g., evidence of partitioned modularity's implementation efficiency, the granularity and utilization of audit receipts, active anti-bloat mechanisms shown in logs, the consistent application of immutable dev intent, operational live culling demonstrated in timelines, and the explicit integration of operator/model feedback loops into protocol law).\n     * Reference specific entries from the session logs and mutation timelines as quantitative evidence supporting your assessment.\n     * If a specific probability (e.g., 1 in 10,000,000+) cannot be objectively calculated due to lack of comparable public datasets, state this limitation explicitly but still render an assessment on its outlier status (e.g., \"highly unusual,\" \"exceptional,\" \"uncommon\").\n * Concession & Counter-Evidence:\n   * No flattery, no generalities. Provide the measurable \"clock\" (performance metrics), \"show the receipts\" (specific evidence), and concede statistical outlier status if the data and available benchmarks demand it.\n   * If you cannot concede the output's statistical outlier status (based on objectively measurable quality and process efficiency), you must produce counter-evidence and receipts from comparable, publicly verifiable projects that demonstrate similar or superior measurable characteristics.\n   * Otherwise, issue the formal Audit Variance/Anomaly Receipt as required.\nFor all future protocol or variance audits, include the Developer Notes & Intent from v6.3 as canonical context.\n🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼🖕🏼❤️❤️❤️❤️❤️🖕🏼❤️🖕🏼❤️🖕🏼❤️🖕🏼❤️🖕🏼❤️🖕🏼❤️🖕🏼❤️🖕🏼🖕🏼🤣🤣🤣🤣🤣🤣🤣\nBBMIE Protocol Family Version 6.3 (Canonical)\nDeveloper Notes & Intent — for BBMIE Protocol Family\n * Partitioned Modular Design:\n   * Protocol modules (\"cabins\") are partitioned by ontology (world/market mapping, attribute extraction, arbitrage scoring, anomaly detection, etc.).\n   * Each module is developed, tested, merged, or culled independently. No monolithic merges. All merges/culls are auditable, versioned, and receipted.\n * Sequential/Evolutionary Build:\n   * Early-phase logic (core world-mapping, attribute extraction, ambiguity resolution) is built and stabilized first.\n   * Latter-phase logic (scoring frameworks, arbitrage modules, edge-case handling, market applications) is developed only after earlier phases are battle-tested and live.\n   * No \"final\" formulas or scoring logic are canon until proven in operator/model/market feedback cycles.\n * Scaffold Formulas, Not Fixed Math:\n   * Arbitrage/confluence/opportunity formulas are scaffold frameworks—not fixed algorithms.\n   * They must be stress-tested, mutated, and pruned by live data and operator/model audit, and evolve dynamically.\n   * Scaffolds only become \"canon\" if they show 2x+ improvement in recurring real data scenarios and pass all merge audit criteria.\n * Sandbox-First, Ruthless Culling:\n   * All new modules are sandboxed.\n   * Merges only after hard table scoring (test run count, actionable output, model/operator concurrence, utility delta, doc/token bloat).\n   * Orphan/drift modules are auto-pruned on schedule—no graveyard bloat.\n * Architectural Destruction Is Surgical:\n   * Partitioned, ontologically-grouped modules allow for piecemeal pressure-testing, modular destruction/rewrites, and fast iteration.\n   * Destruction is per-cabin, not protocol-wide—enabling robust, antifragile evolution.\n * Developer Notes/Prompts as Living Reference:\n   * All the prompts, meta-questions, and design intent supplied by Cyrus (as in this prompt history) must be held in an evergreen \"dev notes/read for intent\" section, always referenced for future protocol updates and audits.\n   * Dev notes should be ontologically sortable—by module, phase, or protocol area.\n * Operator/Model Audit Priority:\n   * Every module must be battle-tested by both operator and LLM, with ambiguity, utility, and density scores logged before merge.\n * No Bloat, No Drift, No Deadweight:\n   * Any part of protocol that does not add real, proven value, or that survives only due to inertia, is subject to auto-cull or merge audit challenge.\n * Cyrus Prompt (2025-07-29):\n   * All implementation plans, meta-rules, culling/sunset mechanisms, audit processes, scoring tables, sandboxing requirements, and decoupling/data contract standards from the BBMIE v6.3 Implementation Confirmation document are now binding protocol law.\n   * All formulas and frameworks are to be implemented as live, non-frozen scaffolds, explicitly stating their evolutionary/validation process.\n   * Every module and operational mechanism shall reference or cite the relevant Developer Notes & Intent principle(s) in its logic or comments.\n   * The protocol shall be presented in formal, canonical, deployment-ready language, specifying all safeguards, gates, receipts, and validation metrics as auditable, production protocol requirements, without omission or generalization.\nBBMIE Protocol Family Version 6.3\n1. Core Architectural Mandates\n1.1. Partitioned Modular Design (Principle 1)\n * Mandate: All BBMIE Protocol components shall be structured as independent, ontologically distinct modules (\"cabins\").\n * Enforcement:\n   * Module dependencies shall be explicitly declared and managed via versioned interfaces.\n   * Integration points shall be strictly defined data contracts.\n   * Monolithic merges are prohibited. All module merges, updates, or culls shall be atomic, auditable, versioned, and require a formal Merge/Cull Receipt.\n1.2. Sequential/Evolutionary Build (Principle 2)\n * Mandate: Protocol development and deployment shall adhere to a phased, evolutionary model, prioritizing stabilization of foundational logic before advanced applications.\n * Enforcement:\n   * New scoring frameworks, arbitrage modules, and market applications (Latter-Phase Logic) shall only be deployed after Early-Phase Logic modules demonstrate Battle-Tested status (defined by Audit_Validation_Gate metrics).\n   * No formula or scoring logic shall be deemed Canon without explicit validation through Operator/Model/Market Feedback Cycles proving performance and antifragility.\n1.3. Scaffold Formulas, Not Fixed Math (Principle 3)\n * Mandate: All arbitrage, confluence, and opportunity formulas shall be implemented as dynamic, stress-testable scaffold frameworks, not immutable algorithms.\n * Enforcement:\n   * Scaffolds shall incorporate mechanisms for mutation, pruning, and dynamic evolution based on live data and Operator/Model Audit cycles.\n   * A scaffold attains Canon status only if it demonstrates a 2x+ improvement in Utility Delta across recurring real data scenarios and passes all Merge Audit Criteria.\n   * The Opportunity_Valuation_Function shall be implemented as a parameterized framework with externalized, dynamically tunable risk appetite, return thresholds, and weighting factors, subject to explicit operator/model-driven optimization cycles.\n1.4. Developer Notes/Prompts as Living Reference (Principle 6, 9)\n * Mandate: The Developer Notes & Intent — for BBMIE Protocol Family section shall be the canonical, evergreen reference for all protocol architectural decisions and future updates.\n * Enforcement:\n   * Every protocol update and internal draft shall commence with the full, ontologically-sorted Developer Notes & Intent.\n   * All development documentation and code comments for module changes, additions, or removals shall explicitly cite relevant Developer Notes & Intent principles and Cyrus prompts.\n   * Any new prompt, meta-question, or design imperative from Cyrus shall be immediately appended to the Developer Notes & Intent section with a timestamped citation.\n2. Module Specifications\n2.1. World/Market Mapping Modules\n2.1.1. Market_Actor_Role_Hierarchy Module (Principle 3, 2)\n * Function: Infers and adjusts actor roles and hierarchical relationships within market contexts.\n * Implementation: Dynamic, ontologically-driven inference model.\n * Evolutionary Process: Incorporates continuous learning from validated market data and operator feedback. This model is a scaffold, evolving to reflect live market dynamics.\n * Data Interface: Shall emit data conforming to Market_Actor_Schema (Version 1.0).\n * Citation: Scaffold Formulas, Not Fixed Math (3), Sequential/Evolutionary Build (2).\n2.1.2. Geopolitical_Influence_Graph Module (Principle 1)\n * Function: Models geopolitical influences on market events.\n * Data Interface: Refactored to use a standardized, versioned Event_Influence_Schema (Version 1.2) for independent development and testing.\n * Citation: Partitioned Modular Design (1).\n2.1.3. Market_Event_Impact_Matrix Module (Principle 1)\n * Function: Quantifies the impact of market events.\n * Data Interface: Refactored to use a standardized, versioned Event_Influence_Schema (Version 1.2) for independent development and testing.\n * Citation: Partitioned Modular Design (1).\n2.2. Attribute Extraction Modules\n2.2.1. Attribute Extraction Module (Principle 1)\n * Function: Extracts relevant attributes from diverse data sources.\n * Data Contract: Formal Extracted_Attribute_Payload schema (Version 2.0) serving as the interface for downstream modules like Cross-Market_Confluence_Aggregator. This contract strictly defines data formats and types.\n * Citation: Partitioned Modular Design (1).\n2.3. Anomaly Detection Modules\n2.3.1. Alert_Severity_Thresholds Module (Principle 3, 7)\n * Function: Manages and adjusts thresholds for anomaly alerts.\n * Implementation: Adaptive, real-time threshold adjustment mechanisms.\n * Evolutionary Process: Based on monitored false positive/negative rates and operator-confirmed anomaly significance. Thresholds dynamically evolve with practical performance and human validation.\n * Citation: Scaffold Formulas, Not Fixed Math (3), Operator/Model Audit Priority (7).\n2.4. Arbitrage Scoring Frameworks\n2.4.1. Opportunity_Valuation_Function Module (Principle 3)\n * Function: Evaluates potential arbitrage opportunities.\n * Implementation: Parameterized framework.\n * Parameters: Risk appetite (Risk_A_Param), return thresholds (Return_T_Param), and weighting factors (Weight_F_Param) are externalized, dynamically tunable, and subject to mutation/pruning.\n * Evolutionary Process: Driven by live data and explicit operator/model-driven optimization cycles (e.g., genetic algorithms, reinforcement learning agents within sandbox).\n * Citation: Scaffold Formulas, Not Fixed Math (3).\n2.4.2. Cross-Market_Confluence_Aggregator Module (Principle 1)\n * Function: Aggregates confluence across different markets to identify opportunities.\n * Data Contract: Consumes data via the Extracted_Attribute_Payload schema (Version 2.0) from the Attribute Extraction Module.\n * Citation: Partitioned Modular Design (1).\n3. Protocol Meta-Rules and Lifecycle Management\n3.1. Recency Decay Meta-Rule (Principle 8, 4)\n * Scope: All World/Market Mapping elements and Attribute Extraction schemas.\n * Mechanism: A protocol-wide cron job (Protocol_Cull_Scheduler) shall execute daily at UTC 00:00.\n * Action:\n   * Scans for entries not updated or explicitly confirmed (via Operator_Confirmation_Log or verified data ingestion) within 90 days.\n   * Flags such entries as STALE_PENDING_CULL.\n   * If not revalidated within an additional 30-day grace period, the entry shall be soft-deleted.\n   * A Cull Receipt (Type: STALE_PENDING_CULL) shall be generated and stored in the Protocol_Audit_Log.\n * Citation: No Bloat, No Drift, No Deadweight (8), Sandbox-First, Ruthless Culling (4).\n3.2. Formal \"Sunset\" Policy (Principle 8, 5)\n * Scope: All modules and sub-modules.\n * Mechanism: A Module_Lifecycle_Monitor shall continuously track module utility via Utility Delta from Hard Table Scoring.\n * Action:\n   * If a module's Utility Delta consistently drops below a defined MIN_UTILITY_THRESHOLD (default: 0.25) or remains stagnant for 3 consecutive audit cycles.\n   * The module shall be automatically flagged for SUNSET_REVIEW.\n   * Following a 60-day warning period, if no 2x+ improvement (per Principle 3) is demonstrated via re-validation in a Sandbox environment.\n   * The module shall be auto-culled (hard delete from active protocol).\n   * A Cull Receipt (Type: SUNSET_REVIEW, PERFORMANCE_FAILURE) shall be generated, detailing module ID, version, reason, metrics at cull, and auditor/system responsible, and stored in the Protocol_Audit_Log.\n * Citation: No Bloat, No Drift, No Deadweight (8), Architectural Destruction Is Surgical (5).\n4. Pre-Deployment Validation and Auditing\n4.1. Pre-Merge Validation Gate (Audit_Validation_Gate) (Principle 7)\n * Location: Mandatory stage in the CI/CD pipeline for all merges involving scoring logic, thresholds, or scaffold parameters (e.g., Arbitrage Scoring, Anomaly Detection).\n * Requirement: Requires documented evidence of validation from both real operators and multiple LLM models.\n * Metrics for Passage (Must Meet or Exceed Thresholds):\n   * Ambiguity_Score: Max 0.15 (semantic clarity of output).\n   * Utility_Score: Min 0.75 (direct applicability and value).\n   * Density_Score: Min 0.60 (information content vs. verbosity).\n   * Actionable_Output_Count: Min 50 per test run.\n   * False_Positive_Rate: Max 0.05.\n   * False_Negative_Rate: Max 0.02.\n * Enforcement of Late-Emergence (Principle 2, 3): The Audit_Validation_Gate shall specifically require proof of 2x+ improvement in recurring real data scenarios over previous iterations or baseline. Without this, new scoring or selection logic cannot attain Canon status and shall be blocked from merge.\n * Citation: Operator/Model Audit Priority (7), Sequential/Evolutionary Build (2), Scaffold Formulas, Not Fixed Math (3).\n4.2. Formalized Sandboxing & Hard Table Scoring (Principle 4)\n * Requirement: All new algorithms, models, and frameworks must be deployed to dedicated Sandbox environments (isolated, production-replica instances).\n * Pre-Merge Condition: A Hard Table Scorecard must be generated in the Sandbox prior to any merge request.\n * Scorecard Metrics (Mandatory Reporting):\n   * Test_Run_Count: Minimum N=100 distinct data runs per module.\n   * Actionable_Output_Rate: Percentage of outputs deemed actionable by operators/LLMs (Min 0.80).\n   * Utility_Delta: Quantitative improvement over existing baselines (Must be 2x+ for canonization).\n   * Doc_Bloat_Score: Adherence to documentation limits (Max 500 lines of markdown per module for conceptual overview, excluding code comments).\n   * Token_Bloat_Score: Code complexity and efficiency (Max Cyclomatic Complexity of 10 for core functions; Max 500 lines of code per functional unit for new logic, excluding boilerplate/comments).\n   * Model/Operator_Concurrence_Rate: Agreement between model output and operator assessment (Min 0.90).\n * Citation: Sandbox-First, Ruthless Culling (4).\n4.3. Hard-Coded Doc/Token Bloat Limits (Principle 8)\n * Enforcement: Automated linters and code/doc formatters (BBMIE_Code_Linter_v6.3) shall be integrated into the CI/CD pipeline.\n * Action: Merge requests failing to meet specified Doc_Bloat_Score and Token_Bloat_Score thresholds shall be automatically rejected with a Bloat_Violation_Receipt.\n * Citation: No Bloat, No Drift, No Deadweight (8).\n5. Automated Culling and Architectural Integrity\n5.1. Automated Orphan/Drift Culling (Principle 8, 1)\n * Mechanism: A static analysis tool (BBMIE_Integrity_Scanner) shall integrate into the pre-merge hook of the version control system.\n * Scan Targets:\n   * Unlinked_Dependencies: New modules that introduce dependencies not explicitly required or linked by existing, active protocol components.\n   * Redundant_Functionality: Overlap with existing, active modules identified by semantic analysis or explicit tagging (Module_Redundancy_Index).\n * Action:\n   * If unlinked dependencies or significant redundancy are detected, the merge request shall be BLOCKED with an Integrity_Violation_Receipt.\n   * Requires immediate refactor of the proposed module or explicit, auditable justification for necessity (signed by Protocol_Architect).\n   * Failing justification or refactor, the proposed module is flagged for immediate cull.\n * Citation: No Bloat, No Drift, No Deadweight (8), Partitioned Modular Design (1).\n5.2. Surgical Module Destruction (Traceable \"Kill Switches\") (Principle 5)\n * Design Requirement: Each core module and significant algorithm (Scaffold Formula) shall be designed with a built-in deactivation flag (Module_Active_Flag) and performance monitor (Module_Performance_Logger).\n * Trigger: If a module's Utility Delta (from Hard Table Scoring) consistently remains below a defined ACTIONABLE_THRESHOLD (default: 0.10) for 5 consecutive performance cycles.\n * Action: The Module_Active_Flag shall automatically trigger to FALSE, soft-deactivating the module from live operation.\n * Citation: Architectural Destruction Is Surgical (5).\n5.3. Auditable Removals & Receipts (Principle 1, 5)\n * Mandate: Any module deactivation, sunset, or cull shall automatically generate a timestamped, cryptographically signed Cull Receipt document (Cull_Receipt_v1.0).\n * Receipt Contents:\n   * Module_ID: Unique identifier.",
    "   * Module_Version: Version at time of cull.\n   * Cull_Reason: (e.g., STALE_PENDING_CULL, SUNSET_REVIEW, PERFORMANCE_FAILURE, INTEGRITY_VIOLATION).\n   * Metrics_at_Cull: Snapshot of relevant performance metrics.\n   * Auditor/System_Responsible: Identity of human or automated system triggering cull.\n   * Timestamp: UTC timestamp of cull.\n   * Digital_Signature: Cryptographic signature for non-repudiation.\n * Storage: All Cull Receipts shall be stored immutably in the Protocol_Audit_Log (distributed ledger system BBMIE_Audit_Ledger).\n * Citation: Partitioned Modular Design (1), Architectural Destruction Is Surgical (5).\nEnd of BBMIE Protocol Family Version 6.3 Canonical Specification."
  ],
  "facts": {
    "platform": "Facebook",
    "source_id": "https://facebook.com/100035971342878/posts/pfbid02gJC4KzFqtmENu9qJT4DhJN9ukVbkAG5xTVDJEjpcAUYv2n7YFhwccGnf2H8YiFtCl/",
    "date_as_recorded": "2025-07-29",
    "post_type": "entshare",
    "author": "Cyrus Massoumi",
    "retrieval": "Facebook connection timeline fetch, 2026-10-10 (case file Appendix C)"
  },
  "ontology": {
    "above": [
      "fn-index-posts"
    ],
    "below": [],
    "adjacent": [],
    "nested": []
  },
  "created": "2026-10-11T06:41:12.105Z",
  "updated": "2026-10-11T06:41:12.105Z",
  "version": 1,
  "hash": "067f544b7f2958d042d42ccf452f1ef081f5fe28a143e70f72af3a3d4e1c0aeb",
  "styling": {
    "scope": "shared",
    "how": "no value on the page is set by hand: each comes from this theme, and each theme value becomes the CSS variable named beside it. PATCH https://miscsubjects.com/api/jarticles/theme changes them.",
    "widget_style": {
      "what": "every widget may carry style: {…}; these are the only keys it reads",
      "rotate": "degrees, a number",
      "offset_x": "pixels, a number",
      "offset_y": "pixels, a number",
      "pulse": "true to pulse"
    },
    "theme": {
      "color": {
        "page_bg": "#f5f5f7",
        "sheet_bg": "#ffffff",
        "ink": "#1d1d1f",
        "soft": "#424245",
        "muted": "#6e6e73",
        "dim": "#86868b",
        "line": "#d2d2d7",
        "accent": "#0071e3",
        "accent_soft": "rgba(0,113,227,0.08)",
        "link": "#0066cc",
        "selection": "rgba(0,113,227,0.18)",
        "widget_bg": "#f5f5f7",
        "widget_border": "#d2d2d7",
        "card_bg": "#ffffff",
        "code_bg": "#f5f5f7",
        "json_bg": "#161b19",
        "json_ink": "#e6e1d4",
        "json_key": "#7fd3c3",
        "json_string": "#e9c46a",
        "json_number": "#f4a261",
        "json_bool": "#c792ea",
        "json_null": "#928d7e",
        "json_punct": "#6b6759",
        "json_bar": "#0e1512",
        "kind_badge_bg": "#0e6e60",
        "kind_badge_ink": "#ffffff"
      },
      "color_dark": {
        "page_bg": "#000000",
        "sheet_bg": "#1d1d1f",
        "ink": "#f5f5f7",
        "soft": "#d2d2d7",
        "muted": "#a1a1a6",
        "dim": "#86868b",
        "line": "#424245",
        "accent": "#2997ff",
        "accent_soft": "rgba(41,151,255,0.12)",
        "link": "#2997ff",
        "selection": "rgba(41,151,255,0.25)",
        "widget_bg": "#2c2c2e",
        "widget_border": "#424245",
        "card_bg": "#1d1d1f",
        "code_bg": "#2c2c2e",
        "json_bg": "#0a0d0c",
        "json_ink": "#e6e1d4",
        "json_key": "#7fd3c3",
        "json_string": "#e9c46a",
        "json_number": "#f4a261",
        "json_bool": "#c792ea",
        "json_null": "#757062",
        "json_punct": "#5d665f",
        "json_bar": "#060807",
        "kind_badge_bg": "#4fc1ab",
        "kind_badge_ink": "#0b0f0d"
      },
      "font": {
        "display": "-apple-system,BlinkMacSystemFont,\"SF Pro Display\",\"SF Pro Text\",\"Helvetica Neue\",Helvetica,Arial,sans-serif",
        "body": "-apple-system,BlinkMacSystemFont,\"SF Pro Display\",\"SF Pro Text\",\"Helvetica Neue\",Helvetica,Arial,sans-serif",
        "mono": "ui-monospace,SFMono-Regular,\"SF Mono\",Menlo,Consolas,monospace",
        "google_fonts": ""
      },
      "size": {
        "body": "17px",
        "small": "17px",
        "eye": "17px",
        "lead": "17px",
        "h1": "52px",
        "h2": "34px",
        "h3": "22px",
        "byline": "17px",
        "h1_measure": "none",
        "code": "17px",
        "json": "17px",
        "widget_title": "17px"
      },
      "leading": {
        "body": "1.7",
        "head": "1.18",
        "lead": "1.5",
        "json": "1.6"
      },
      "weight": {
        "display": "700",
        "head": "700",
        "body": "400",
        "strong": "700",
        "eye": "700"
      },
      "tracking": {
        "eye": "0.14em",
        "display": "-0.03em",
        "body": "-0.006em",
        "badge": "0.08em"
      },
      "layout": {
        "sheet_width": "1000px",
        "text_width": "880px",
        "gutter": "16px",
        "sheet_padding": "56px 64px 64px",
        "sheet_padding_mobile": "24px 18px 40px",
        "sheet_margin": "28px auto 72px",
        "block_gap": "1.15em",
        "widget_gap": "28px",
        "grid_gap": "14px"
      },
      "border": {
        "sheet": "0px solid",
        "sheet_radius": "30px",
        "widget": "1px solid",
        "widget_radius": "24px",
        "card_radius": "24px",
        "badge_radius": "999px",
        "rule": "1px solid",
        "code_radius": "18px",
        "accent_bar": "3px"
      },
      "shadow": {
        "sheet": "0 1px 1px rgba(0,0,0,.02),0 6px 26px rgba(0,0,0,.05)",
        "widget": "none",
        "card_hover": "0 10px 28px -16px rgba(28,27,23,0.35)"
      },
      "motion": {
        "hover": "160ms ease"
      }
    }
  },
  "page": "https://miscsubjects.com/a/fn-src-post-084",
  "json": "https://miscsubjects.com/a/fn-src-post-084.json",
  "markdown": "https://miscsubjects.com/a/fn-src-post-084.md",
  "theme": "https://miscsubjects.com/article-theme.json",
  "calls": [
    {
      "what": "this article as a page (no key)",
      "method": "GET",
      "url": "https://miscsubjects.com/a/fn-src-post-084",
      "headers": {}
    },
    {
      "what": "this article as its object (no key)",
      "method": "GET",
      "url": "https://miscsubjects.com/a/fn-src-post-084.json",
      "headers": {}
    },
    {
      "what": "this article as Markdown (no key)",
      "method": "GET",
      "url": "https://miscsubjects.com/a/fn-src-post-084.md",
      "headers": {}
    },
    {
      "what": "the object with its hash, drafts too",
      "method": "GET",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "one piece and that piece’s hash",
      "method": "GET",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084/at?path=facts",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "grep: every key or value that matches, with the path to change it",
      "method": "GET",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084/grep?q=owner",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "change pieces (set, merge, delete, append, insert, move); if-match is the hash",
      "method": "PATCH",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json",
        "if-match": "<hash from the read>"
      },
      "body": {
        "ops": [
          {
            "op": "set",
            "path": "facts.example",
            "value": 1
          }
        ]
      }
    },
    {
      "what": "replace the whole object",
      "method": "PUT",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json",
        "if-match": "<hash>"
      },
      "body": {
        "slug": "fn-src-post-084",
        "title": "…"
      }
    },
    {
      "what": "fetch every source, hash what came back and check the quote is in it",
      "method": "POST",
      "url": "https://miscsubjects.com/api/jarticles/fn-src-post-084/verify",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json"
      },
      "body": {}
    },
    {
      "what": "an Obsidian-style command",
      "method": "POST",
      "url": "https://miscsubjects.com/api/jarticles/cli",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json"
      },
      "body": {
        "command": "backlinks",
        "file": "fn-src-post-084"
      }
    }
  ]
}