Whitepaper Condenser & Rewriter

Triage - Core claims - Open submission: anyone can submit an AI agent for testing. - Standardized evaluation: each agent receives a fixed set of test tasks. - Dual review: answers are automatically checked, then reviewed by independent evaluators. - Transparent scoring: scores are combined into a letter grade (A–F) and published on a public leaderboard. - Continuous measurement: agents can be retested and grades update over time. - Definitions (as used here) - AI agent: a software system that takes inputs and produces outputs to complete defined tasks. - Test task: a well-specified prompt, input, or scenario with a target outcome and rubric. - Automatic checking: programmatic evaluation (e.g., exact match, metrics, or rule-based validators). - Independent evaluators: human reviewers not affiliated with the submitting team. - Leaderboard: a public, versioned registry of agents and grades. - Goals - Comparability across agents, transparency of results, and durability of grades over time. - Gaps/Assumptions [clarify] - Scope of task domains; rubric details and weighting; mapping from numeric score to A–F; evaluator selection and compensation; anti-gaming measures; reproducibility policy; access controls and IP handling; cost model and submission limits; retest cadence and triggers; hardware/compute normalization; appeals process. Outline (estimated word counts) - Executive Summary (≤250) - Introduction (200) - Problem (250) - Prior Art/Context (250) - System Overview (300) - Architecture (800) - Submission & Registration; Task Catalog & Versioning; Execution Sandbox; Automated Evaluation; Human Review; Scoring & Grading; Leaderboard; Retesting; Storage & Audit; Security. - Protocol/Economics (200) [clarify] - Security & Limitations (350) - Roadmap (250) - Governance (250) - Risks (250) - Conclusion (150) - FAQs (400) - Glossary (200) - References [placeholders] - Callouts: Assumptions, Open Questions, Future Work - Diagram List with captions - One-page SME Review Checklist Executive Summary (≤250 words) This whitepaper specifies a standardized platform for evaluating AI agents. Anyone can submit an agent to be tested on a fixed, versioned suite of tasks. Responses are scored through a two-stage process—automated checks followed by independent human review—to balance objectivity with qualitative judgment. Scores are combined into a single, interpretable letter grade (A–F) and published on a public leaderboard. Agents may be retested, and grades update over time to reflect improvements, regressions, or changes in the test suite. The system emphasizes comparability, transparency, and reproducibility. Core components include a secure submission interface, execution sandbox, automated evaluation engine, human review portal, scoring and grade-mapping service, and a public leaderboard with full audit trails. Governance covers evaluator independence, conflict-of-interest policies, appeals, and version control for tasks and rubrics. Open questions remain regarding weighting schemes, evaluator incentives, and anti-gaming safeguards; these are flagged for stakeholder review. The result is a credible, durable signal of agent performance that is simple to interpret yet grounded in rigorous assessment. Full Structured Draft Introduction AI agents are proliferating across research and industry, but their reported capabilities are often hard to compare. Benchmarks vary, metrics differ, and evaluation practices are inconsistent. A public, standardized platform with transparent scoring and independent oversight can improve comparability and trust in results. This document defines such a platform based on five core claims: open submission, fixed test tasks, dual (automated + human) review, letter grades on a public leaderboard, and ongoing retesting. Problem Current evaluation practices face several issues: fragmented test suites, metric inconsistency, selective reporting, and limited reproducibility. Without a unified framework, end users and researchers struggle to interpret performance claims and track progress over time. Moreover, many tasks require nuanced human judgment that automated checks alone cannot capture, while fully manual grading is costly and potentially inconsistent. A balanced system that integrates automation with independent review can provide both scale and legitimacy. Publishing a single A–F letter grade enhances accessibility for non-experts while retaining detailed audit trails for experts. Prior Art/Context (high-level) Prior work includes static benchmarks and leaderboards, community competitions, and peer-review processes [REF]. Static benchmarks enable comparability but can be gamed or overfit. Competitions encourage innovation but often lack durable, versioned grades. Peer review brings human judgment but is not standardized for repeatability. This platform combines their strengths: fixed and versioned task sets, reproducible automated scoring, structured independent evaluation, and a clear grade mapping with public visibility. System Overview At a high level, the platform lifecycle is: (1) submission and registration of an agent; (2) assignment of a fixed, versioned task suite; (3) execution in a sandboxed environment; (4) automated evaluation; (5) independent human review where needed; (6) score aggregation and grade mapping; (7) publication on a public leaderboard; and (8) optional retesting that can update grades. Key properties include: standardized tasks and rubrics; clear versioning; full logs for reproducibility; strict separation between submitters and evaluators; and audit trails for any grade changes. Anti-gaming and fairness controls include task randomization within fixed pools, hardware normalization where applicable, and conflict-of-interest checks for evaluators [REF]. Architecture - Submission & Registration - Secure upload of agent binaries or endpoints; metadata capture (version, dependencies, intended modalities) [clarify]. - Policy checks: license/IP declarations, safety attestations, and compute limits. - Task Catalog & Versioning - Curated, fixed test suites tagged by domain and difficulty; semantic versioning with deprecation policies. - Rubrics define acceptance criteria, metrics, and when human review is required. - Execution Sandbox - Isolated runtime to prevent data exfiltration and ensure fair resource allocation (CPU/GPU quotas, network rules) [REF]. - Deterministic seeding where feasible; environment hashing for reproducibility. - Automated Evaluation - Deterministic validators (e.g., exact/regex match), metric-based scorers (e.g., accuracy, BLEU-like, latency), and rule-based safety checks. - Confidence signals determine whether a sample escalates to human review. - Human Review Workflow - Blind, independent evaluators follow standardized rubrics; double-blind when possible. - Inter-rater reliability tracked (e.g., Cohen’s kappa) with adjudication for disagreements [REF]. - Scoring & Grading Engine - Sample-level scores aggregated to task-level, then to suite-level via weighted means [clarify weights]. - Bias/variance adjustments and normalization across task versions where needed [clarify]. - Grade mapping converts a numeric score to A–F via transparent thresholds [clarify]. - Leaderboard Service - Public, queryable listings with agent metadata, grade, date, and version tags; diff views for retest deltas. - Downloadable audit packets (logs, seeds, metrics, human annotations) subject to policy. - Retesting & Version Control - Triggers: new agent version, periodic refresh, or suite updates. - Historical grades retained; latest grade displayed by default with links to prior results. - Data Storage & Audit - Tamper-evident logs; per-run manifests; cryptographic signatures for artifacts [REF]. - PII handling and content safety pipelines where applicable [clarify]. - Security & Compliance - Access control for private submissions; sandbox egress policies; malware scanning. - COI declarations for evaluators; audit trails for grade changes. Protocol/Economics (if any) No token or incentive mechanism is specified in the source material [clarify]. Possible models (to be decided): submission fees to cover compute; stipends for evaluators; sponsorships for task maintenance; or an open, grant-funded baseline. Pricing, quotas, and hardship waivers require explicit policy choices [clarify]. Security & Limitations - Cheating/overfitting risk if tasks leak; mitigate via versioning, pools, and audit logs. - Hardware/compute disparities can skew performance; use quotas, normalization, or compute-reported tags [clarify]. - Human review variability; mitigate with training, inter-rater monitoring, and adjudication. - Ambiguous tasks; mitigate with clearer rubrics and escalation. - Reproducibility drift across environments; mitigate via containerization and environment hashing. - Safety concerns (harmful content); enforce safety checks and evaluator protections [REF]. - Scope limits: only a “fixed set” is guaranteed; generalization to out-of-scope tasks is not implied. Roadmap - Phase 0 (MVP): core submission, fixed suite v1, automated checks, minimal human review, grade mapping, public leaderboard. - Phase 1: evaluator portal, COI policy, inter-rater tracking, audit packet downloads. - Phase 2: task versioning, pools and randomization, compute normalization, retest scheduler. - Phase 3: appeals workflow, richer metrics, safety pipelines, expanded domains. - Phase 4: community governance for task curation, external audits, formal reproducibility reports. Governance - Evaluator independence: selection criteria, COI declarations, rotation schedules [clarify]. - Task governance: proposal, review, and versioning with changelogs; sunset/deprecation rules. - Appeals: submitters can request re-reviews under defined conditions. - Transparency: publish rubrics, thresholds, and version histories where feasible; protect IP as required. Risks - Reputation risk from erroneous grades; mitigated by audits and appeals. - Ecosystem gaming (teaching to the test); mitigated by versioning and diverse task pools. - Reviewer bias or fatigue; mitigated by training and monitoring. - Cost overruns for compute and review; mitigated by fees/sponsorships [clarify]. - Legal/IP exposure from submitted artifacts; mitigated by license checks and isolation. Conclusion This platform formalizes a pragmatic, transparent approach to evaluating AI agents. By combining automated checks with independent human review and publishing simple A–F grades on a public leaderboard, it creates a durable, interpretable signal of capability. Clear governance, auditability, and retesting policies ensure that grades evolve with agents and tasks while maintaining trust. FAQs - What does the letter grade represent? - A mapping from aggregated numeric scores to A–F thresholds, published per suite version [clarify thresholds]. - Are tasks public? - Task outlines and rubrics may be public, but individual items may be hidden to reduce leakage [clarify]. - How often can agents be retested? - On new releases or scheduled intervals; policy will define limits to prevent spam [clarify]. - How are independent evaluators chosen? - Via criteria and COI screening; performance tracked with inter-rater metrics [clarify]. - Can submitters appeal a grade? - Yes, through a structured appeals workflow with audit evidence [clarify]. - How is fairness across hardware handled? - By enforcing quotas and/or tagging results with compute metadata; normalization may apply [clarify]. - How are safety concerns addressed? - Automated filters plus reviewer protocols; harmful outputs trigger escalation [REF]. - Is the platform suitable for multimodal agents? - Yes in principle; require modality-specific tasks, validators, and sandboxes [clarify]. - Can proprietary agents participate? - Yes, subject to IP policies and isolation requirements [clarify]. - Will detailed scores be available? - Summary grades are public; downloadable audit packets may include detailed metrics [clarify]. Glossary - Agent: software that performs tasks autonomously or semi-autonomously given inputs. - Task Suite: a versioned collection of tasks used for standardized evaluation. - Rubric: instructions and criteria guiding automated and human scoring. - Automated Check: programmatic validator for an output. - Independent Evaluator: a trained human reviewer without conflicts of interest. - Inter-rater Reliability: agreement metric between evaluators. - Grade Mapping: conversion from numeric score to A–F thresholds. - Leaderboard: public registry of agents and grades with version tags. - Retesting: re-evaluation that can update a grade. - Audit Packet: logs and artifacts enabling external review of a run. References [placeholders] [1] [REF] [2] [REF] [3] [REF] [4] [REF] [5] [REF] Callouts - Assumptions - Fixed suites are representative enough to summarize capability. - Automated checks cover most objective criteria; humans handle nuance. - Public grades create positive incentives for quality. - Open Questions - Exact weighting of automated vs human scores; grade thresholds. - Evaluator incentives and funding model. - Anti-gaming design and leakage controls. - Future Work - Expanded domains and modalities; adversarial robustness tracks. - Longitudinal stability analysis of grades; fairness audits. - Community co-governance of task curation. Diagram List (placeholders) - [Figure: High-Level System Architecture — components and data flows] - [Figure: Evaluation Pipeline — from submission to leaderboard] - [Figure: Scoring & Grade Mapping — aggregation and thresholds] - [Figure: Retesting Lifecycle — triggers and versioning] One-Page “What to Review” Checklist for SMEs - Task Coverage: Are domains and difficulties representative? Any leakage risks? - Rubrics: Are acceptance criteria unambiguous? When is human review triggered? - Scoring: Are weights and thresholds justified and published? Sensitivity analysis done? - Evaluators: Independence, COI policy, training, and inter-rater metrics in place? - Sandbox: Isolation, resource quotas, and reproducibility hashing validated? - Security & Safety: Malware scanning, content filters, and reviewer protections configured? - Leaderboard: Version tags, audit packets, and change logs accessible and tamper-evident? - Retesting: Triggers, cadence, and historical grade retention defined? - Governance: Appeals, transparency, and decision records documented? - Legal/IP: Submission licenses, data handling, and privacy compliance verified?

Executive Summary We grade agents, and some perform poorly. Our grades are based on test tasks and human-style review. This document restates that policy formally, defines key terms, and frames a minimal, implementation-agnostic evaluation specification. Details such as task design, scoring rubrics, reviewer training, and aggregation methods are intentionally left unspecified and marked [clarify] for subject-matter experts (SMEs). The aim is clarity and consistency without altering the underlying claims. Triage - Core claims: 1) We grade agents. 2) Some agents perform poorly. 3) Grades are based on test tasks and human-style review. - Definitions (working): - Agent: an autonomous software system that completes tasks. - Test tasks: predefined tasks used to evaluate agent performance. - Human-style review: qualitative and/or rubric-guided assessments that emulate human judgment. - Goals: Produce a formal, concise restatement and a structured draft around it. - Gaps/Assumptions: - Scope of “agents” (domains, modalities) [clarify]. - Nature of test tasks (coverage, difficulty, sampling) [clarify]. - Review protocol (rubrics, inter-rater reliability, calibration) [clarify]. - Aggregation and reporting (scales, thresholds) [clarify]. Outline (estimated word counts) - Introduction (150) - Problem (150) - Prior Art/Context (high-level) (150) - System Overview (200) - Architecture (illustrative, implementation-agnostic) (250) - Protocol/Economics (if any) (50) - Security & Limitations (200) - Roadmap (150) - Governance (150) - Risks (200) - Conclusion (100) - FAQs (250) - Glossary (100) - References [placeholders] (short) - Callouts: Assumptions, Open Questions, Future Work (100) - Diagram List with Captions (short) - SME Review Checklist (one page, bullets) Full Structured Draft Introduction This document formalizes a minimal evaluation policy: we grade agents; some perform poorly; grades are based on test tasks and human-style review. It defines terms, frames the process at a high level, and identifies areas needing clarification before operationalization. Problem Stakeholders require transparent, repeatable evaluation of agents. Without a stated basis for grading, results can be ambiguous or non-actionable. The core problem addressed here is to state, in formal language, the basis for grading and to signal that low performance is observed for some agents. Prior Art/Context (high-level) Evaluation in AI commonly combines benchmarked tasks with qualitative assessment to capture capabilities and behavior that are difficult to quantify directly [placeholder]. Human-in-the-loop review is standard when nuanced judgment, safety, or reliability must be assessed beyond automated scoring [placeholder]. System Overview Core policy statement (formal rewrite): We grade agents, and some perform poorly. Our grades are based on test tasks and human-style review. Intent: Communicate, at policy level, that (i) grading occurs, (ii) performance varies and may be poor, and (iii) grading draws on both task-based evidence and human-style judgments. Scope: Modalities, domains, and task sources are unspecified [clarify]. Architecture (implementation-agnostic, illustrative) Note: The following is illustrative and not prescriptive; details are [clarify]. - Task Suite: A set of test tasks with defined inputs/outputs [clarify]. - Execution Harness: Runs agents against tasks under controlled conditions [clarify]. - Automated Scoring: Computes task completion metrics where applicable [clarify]. - Human-Style Review: Calibrated reviewers apply rubrics mirroring human judgment [clarify]. - Aggregation & Grading: Combines task and review signals into grades; thresholds/reporting are [clarify]. [Figure: High-level evaluation pipeline] Protocol/Economics (if any) No token, pricing, or economic mechanics are claimed or required. Not applicable. Security & Limitations - Validity: Grades reflect chosen tasks and review criteria and may not generalize beyond them. - Reliability: Human-style review requires calibration and checks for inter-rater agreement [clarify]. - Bias: Task selection and reviewer backgrounds can introduce bias; mitigation steps are [clarify]. - Gaming: Agents may overfit to tasks; rotation and red-teaming are recommended [clarify]. - Reporting: Confidence intervals or uncertainty communication are advisable [clarify]. Roadmap - Define task selection principles and coverage targets [clarify]. - Draft reviewer rubrics and calibration procedures [clarify]. - Specify grade scales, aggregation rules, and reporting formats [clarify]. - Pilot evaluation; analyze variance and reliability; iterate [clarify]. Governance - Roles: Maintainers (task curation), Reviewers (human-style assessments), Operators (execution) [clarify]. - Policies: Conflict-of-interest disclosures; auditability and versioning of tasks/rubrics [clarify]. - Appeals: Process for contesting grades [clarify]. Risks - Misinterpretation: Users may overgeneralize grades; require context and scope statements. - Drift: Tasks or reviewer standards may drift over time; institute periodic recalibration [clarify]. - Confidentiality: Handling of agent outputs and proprietary tasks must respect privacy/IP [clarify]. - Safety: Human reviewers may encounter unsafe content; provide safeguards [clarify]. Conclusion A minimal, formal policy is stated without altering the original claims: we grade agents; some perform poorly; and grades are based on test tasks and human-style review. Operational details are intentionally left for future specification. FAQs - What does “human-style review” mean? Qualitative and/or rubric-guided assessments that emulate human judgment; exact rubric is [clarify]. - Are grades objective? They reflect defined tasks and review criteria; objectivity depends on those choices [clarify]. - What counts as a “test task”? Any predefined evaluation task with clear setup; selection principles are [clarify]. - Do poor grades imply unsafe agents? Not necessarily; safety requires targeted testing and review [clarify]. - How often are grades updated? Update cadence is [clarify]. Glossary - Agent: Autonomous software that performs tasks. - Grade: A summary categorization derived from task performance and human-style review. - Test Task: A predefined evaluation item with expected behavior or outcomes. - Human-Style Review: Assessment approximating human judgment via rubrics or narrative review. - Aggregation: Method for combining signals into a grade [clarify]. References - [placeholder] - [placeholder] - [placeholder] Callouts - Assumptions: Tasks and reviews exist and can be combined into a grade; specifics are TBD [clarify]. - Open Questions: Scope of agents, task domains, reviewer training, aggregation rules, reporting cadence [clarify]. - Future Work: Finalize rubrics, establish reliability targets, publish methodology, release example reports [clarify]. Diagram List (placeholders) - [Figure 1: Evaluation pipeline overview] - [Figure 2: Task bank and execution harness] - [Figure 3: Human-style review workflow] What to Review (SME Checklist) - Terminology: Are “agent,” “test task,” and “human-style review” defined adequately for your context? - Scope: Which domains/modalities are in-scope? What is out-of-scope? - Tasks: Are selection, difficulty, and coverage principles acceptable? - Review: Are rubrics, calibration, and reliability targets specified and practical? - Aggregation: Are grade scales and combination rules clear and defensible? - Reporting: Are uncertainty, caveats, and update cadence defined? - Governance: Are roles, conflicts, audits, and appeals addressed? - Safety & Ethics: Are reviewer protections and bias mitigations planned? - Dependencies: What resources, datasets, or tools are required? - Acceptance: What criteria must be met to move from policy to production?

Triage - Raw material: “What was OpenServ’s exact revenue in March 2026?” - Core ask: Provide a single, precise, verified revenue figure for OpenServ for the period 1–31 March 2026. - Definitions (to confirm): “Revenue” = recognized revenue (not bookings/cash collections) under [clarify: GAAP/IFRS]; “exact” = final, approved, auditable figure; currency [clarify: USD?]; scope [clarify: consolidated vs. business unit]. - Gaps: No financial data provided; recognition policy, currency, entity scope, adjustments (refunds/chargebacks/deferrals), and audit status are unspecified. - Assumptions: Revenue will be reported net of discounts, refunds, chargebacks, taxes; one base currency with FX policy [clarify]. Outline (H2/H3 with estimated word counts) - Executive Summary (200) - Introduction (200) - Problem (Definition & Need for Precision) (180) - Prior Art/Context (Standards & Reporting Norms) (180) - System Overview (How to Derive the Figure) (180) - Architecture (Data Sources, Transformations, Controls) (350) - Data Sources (100) - Transformation & Recognition Logic (120) - Reconciliation & Sign-off (130) - Protocol/Economics (Accounting Treatment & Metrics) (220) - Security & Limitations (180) - Roadmap (Steps to Produce/Publish the Number) (200) - Governance (Ownership & Approvals) (160) - Risks (160) - Conclusion (100) - FAQs (200) - Glossary (150) - References [placeholders] - Diagram List (placeholders) - SME Review Checklist (~1 page) Executive Summary (≤250 words) This document addresses a single question: What was OpenServ’s exact revenue in March 2026? The provided material does not include financial data, policies, or scope definitions, so the precise figure is [clarify]. To deliver an authoritative number, we outline the data pipeline, accounting treatment, reconciliations, and governance required to compute and approve the figure. We define “exact revenue” as the final, recognized amount for March 1–31, 2026, net of discounts, refunds, and taxes, under an explicit standard [clarify: GAAP/IFRS] and currency [clarify]. We specify sources (ERP/GL, billing, payments, data warehouse), recognition logic (accrual rules, deferral schedules), and cross-checks (bank, subledger, analytics). The roadmap culminates in CFO sign-off and publication with provenance. Until those steps are completed, the authoritative value remains [clarify]. Full Structured Draft Introduction The inquiry seeks OpenServ’s exact revenue for March 2026. “Exact” implies a final, approved, auditable figure. “Revenue” refers to recognized revenue within the month, not bookings, cash receipts, or ARR/MRR proxies. Key ambiguities—currency, entity scope, standard (GAAP/IFRS), and net/gross basis—require clarification before a definitive figure can be stated. Problem Without shared definitions and verified source data, monthly revenue can be misstated or inconsistently interpreted. Variability in recognition rules (e.g., performance obligations, deferrals), FX policies, and data completeness exacerbates the risk. The goal is to produce one authoritative, reproducible March 2026 revenue figure for OpenServ with clear provenance and approvals. Prior Art/Context (high-level) Standard revenue recognition frameworks (e.g., ASC 606/IFRS 15) require identifying performance obligations, determining transaction price, and recognizing revenue upon satisfaction of those obligations. Organizations typically derive monthly recognized revenue from ERP/GL and subledgers, reconciling to bank and billing systems, with period-close controls and sign-offs. System Overview We propose a minimal, auditable pipeline to derive March 2026 revenue: ingest authoritative data (ERP/GL, billing, payments), apply recognition logic per policy, reconcile across systems, resolve variances, and obtain controller/CFO approvals. The output is a single figure with a change log, data lineage, and certification status. Architecture - Data Sources: ERP/GL (journal entries), billing (invoices, credits), payments (settlements, chargebacks), data warehouse (usage/entitlements). [clarify: systems used] - Transformation & Recognition Logic: Map products to performance obligations; apply recognition schedules (daily/linear/proportional); handle discounts, refunds, taxes; consolidate multi-entity results; apply FX policy; post deferrals/accruals. [clarify: policies] - Reconciliation & Sign-off: GL ↔ subledger tie-out; bank/processor settlements vs. AR; variance thresholds; issue tracking; controller review; CFO sign-off; audit trail with versioning and data lineage. [Figure: Revenue data flow from sources → transformations → reconciliations → approvals] Protocol/Economics (if any) - Measurement: Recognized revenue for 2026-03-01 to 2026-03-31, net of discounts, refunds, chargebacks, and taxes; gross vs. net presentation [clarify]. - Metrics: MRR/ARR are supplemental and not substitutes for recognized revenue. Deferred revenue roll-forward must reconcile with recognition entries. - FX & Consolidation: Specify functional currency; provide FX sources and rates for translation; eliminate intercompany transactions. Security & Limitations - Security: Restrict access to financial systems; enforce least privilege; log access; protect PII/PCI in payment data. - Limitations: No numeric data provided; cannot state the figure. Dependencies include policy documents, system extracts, and approvals. Roadmap 1) Confirm definitions: scope, currency, basis (net/gross), GAAP/IFRS. 2) Extract March 2026 source data from ERP/GL, billing, payments. 3) Apply recognition policy. 4) Reconcile GL, subledgers, and bank. 5) Resolve variances. 6) Produce a draft figure with lineage. 7) Controller review and CFO sign-off. 8) Publish the final figure with certification. Governance - Ownership: Accounting (primary), FP&A (analytics), Data (pipelines), Security (access), CFO (final approval). - Change Management: Versioned policies, documented exceptions, reproducible runs, and archived artifacts. Risks - Misstatement risk from inconsistent policies or incomplete data. - FX and consolidation errors. - Operational errors in ETL or manual adjustments. - Compliance/audit findings if controls are weak. Conclusion The exact revenue figure for OpenServ in March 2026 is [clarify]. This document specifies how to produce and certify that number. Until definitions are confirmed and reconciliations completed, no authoritative value can be stated. FAQs - Q: What currency is used? A: [clarify] - Q: Net or gross of taxes/fees? A: Net of taxes; processor fees presentation [clarify]. - Q: Recognized revenue vs. bookings/cash? A: Recognized revenue per GAAP/IFRS only. - Q: Is ARR/MRR acceptable? A: No; they are supplemental. - Q: Who signs off? A: Controller then CFO. Callouts - Assumptions: Single consolidated entity; net presentation; GAAP/IFRS applied; FX policy defined. [clarify] - Open Questions: Currency; scope; recognition policy; data systems; approval chain. [clarify] - Future Work: Automate lineage, add variance dashboards, enable external disclosure format. Glossary - Recognized Revenue: Income recorded when performance obligations are satisfied. - Bookings: Signed contract value; not revenue. - ARR/MRR: Annual/Monthly Recurring Revenue; not a GAAP/IFRS measure. - Deferred Revenue: Liability representing obligations yet to be recognized as revenue. - ASC 606/IFRS 15: Revenue recognition standards. References [placeholders] - [Placeholder: OpenServ revenue recognition policy] - [Placeholder: ERP/GL period close checklist] - [Placeholder: FX policy document] Diagram List (placeholders) - Figure 1: Revenue data flow (sources → transformations → reconciliations → approvals). - Figure 2: Recognition timeline for March 2026 (contract start/end, deferrals, recognition window). What to Review (SME Checklist) - Definition of “revenue” (recognized; net vs. gross) is documented. - Reporting scope (entities, products) and currency are specified. - Standard (GAAP/IFRS) and policy references are identified. - Data sources (ERP/GL, billing, payments) are named and accessible. - Extraction windows align to 2026-03-01–2026-03-31 with time zone policy. - Recognition rules for each product and obligation are enumerated. - Discounts, refunds, chargebacks, and taxes are treated consistently. - FX translation policy and rates are pinned for March 2026. - Consolidation and intercompany eliminations are configured. - Reconciliations (GL↔subledgers, bank/processor) are performed with variance thresholds. - Adjusting entries are documented and approved. - Data lineage and reproducibility are captured (inputs, code version, outputs). - Controller review and CFO sign-off are recorded. - Final figure is published with provenance and certification status. - Outstanding [clarify] items are tracked to resolution.