-------------------------------------------------------------------------------- DOCUMENT CONTROL (HEADER) -------------------------------------------------------------------------------- Document ID : DARH_STDS_BPGP_001 Title : BPGP Style Definition, Consolidated Comprehensive Standard for Daralbeida Plain-Text Documents Version : 3.1 Status : DRAFT Classification : Internal; sharable with AI tools and contractors on onboarding Prepared By : PYB / Daralbeida Reviewed By : (pending) Approved By : (pending) Approval Date : (pending) Owner : PYB / Daralbeida Date Created : 2026-05-30 Last Revised : 2026-06-02 00:36 UTC Update Cycle : 90 days Next Review Due : 2026-08-31 Annual Review : 2027-06-02 Retention : Duration of Daralbeida operations; superseded versions kept indefinitely in Archives Department : STDS Style : BPGP Keywords : BPGP, standards, document format, document management, parser contract, glossary block, acronym block, file naming, document ID, controlling reference, consolidated Related Docs : DARH_STDS_BPGP_202605300724.txt (v3.0 base, folded in); DARH_STDS_BPGP_202605301215.txt (v3.1 delta, folded in); DARX_OPS_PROMPTS_BPGP_202605310609.txt (OPS prompt tool, v3.1) Supersedes : DARH_STDS_BPGP_202605300724.txt (v3.0 base); DARH_STDS_BPGP_202605301215.txt (v3.1 delta) Superseded By : (none, current version) -------------------------------------------------------------------------------- OUTLINE -------------------------------------------------------------------------------- 1. Purpose and Scope 1.1 What This Standard Is 1.2 What BPGP Covers 1.3 What BPGP Does Not Cover 1.4 Default Application 1.5 Relation to the Viewer Parser 1.6 Consolidation Note 2. What BPGP Is and the Four Core Obligations 2.1 Definition 2.2 Completeness 2.3 Consistency 2.4 Precision 2.5 Standalone Operability 2.6 Brevity Is Not a Goal 3. The Three Formatting Rules (R1, R2, R3) 3.1 R1, Single-Line Paragraphs 3.2 R2, Mandatory AI Prompts Section 3.3 R3, 80-Character Non-Paragraph Limit 4. Document Anatomy, Required Sections in Order 4.1 Position-by-Position Layout 4.2 Section Position Rules 4.3 Section Count Target 5. Header Control Block 5.1 Template 5.2 Required Fields, in Order 5.3 Label Column Width 5.4 Continuation of Long Values 5.5 Field-by-Field Definitions 6. Outline Block 6.1 Position and Markers 6.2 Outline Formatting Rules 6.3 Sub-Section and Sub-Sub-Section Entries 6.4 First-Word Rule, Viewer Navigation 6.5 Outline Example 7. Section Structure 7.1 Top-Level Headings, Bar-Title-Bar Parser Contract 7.2 Sub-Section Headings 7.3 Sub-Sub-Section Headings 7.4 Section Numbering Rules 8. Body Text Rules 8.1 Single-Line Paragraphs, R1 in Practice 8.2 Voice, Tense, and Case 8.3 Paragraph Spacing 8.4 Indentation Levels 8.5 Numbers in Prose 8.6 Date Formats 8.7 Cross-References 9. Table, List, and Special Block Formatting 9.1 Tables, Structure 9.2 Tables, the Box-Drawing Separator Parser Contract 9.3 Tables, Column Alignment Rules 9.4 Tables, Null Cells and Width Constraint 9.5 Lists, Unordered 9.6 Lists, Ordered and Lettered 9.7 Lists, Rules and Prohibited Markers 9.8 Sub-Label Block, Uppercase plus Colon 9.9 Template Block, Quote with Gold Border 9.10 Horizontal Rule Inside a Section 9.11 Acronym Block, Formal Definition (Form A and Form B) 9.12 Glossary Block, Formal Definition (Form A and Form B) 9.13 Inline Acronym Auto-Boxing, ACRONYM_EXCEPTIONS 10. Prohibited Elements 10.1 Markup of Any Kind 10.2 Bullet Symbols 10.3 Hyphen in Names or Document IDs 10.4 Line Breaks Inside a Paragraph 10.5 Non-Paragraph Lines Over 80 Characters 10.6 ASCII Hyphen as a Table Column Separator 10.7 Decorative or Non-Functional Characters 11. Naming Conventions 11.1 File Naming, Current Convention 11.2 Entity Codes 11.3 Category Codes 11.4 Dynamic Directory Placement 11.5 Legacy File Naming Conventions, Superseded 11.6 Document ID Convention 11.7 Department Codes 11.8 Type Codes 11.9 File Name and Document ID Are Distinct 12. Document Management Fields 12.1 Status Lifecycle 12.2 Approval Fields 12.3 Date and Time Fields, UTC 12.4 Update Cycle and Next Review Due 12.5 Annual Review 12.6 Lineage Fields, Supersedes and Superseded By 12.7 Keywords 12.8 Version Numbering 12.9 Review Triggers 12.10 Retention 12.11 COMPLIANCE Field 13. Document Control Footer 13.1 Trigger Line, Exact String 13.2 Required Fields 13.3 Distribution 13.4 Revision History Pointer 13.5 END OF DOCUMENT Line, Exact String 14. Pre-Publication Checklist 14.1 Structure Checklist 14.2 Content Checklist 14.3 DMS Field Checklist 14.4 Daralbeida Brand Compliance Checklist 14.5 v3.1 Glossary and Acronym Block Checklist 15. AI Prompts 15.1 Purpose 15.2 Position 15.3 Rules for Each Prompt Block 15.4 Editable Tokens 15.5 Multiple Prompts 15.6 Regeneration Prompt for This Standard 15.7 BPGP Generator, Copy-Paste Block for Any New Document 16. Revision History 17. Acronyms 18. Glossary DOCUMENT CONTROL (FOOTER) -------------------------------------------------------------------------------- RULE SUMMARY (R1, R2, R3) ================================================================================ Three rules govern every BPGP document. They are stated here for reviewers and specified in full in Section 3. R1 Each body paragraph is a SINGLE unbroken line. No internal line breaks. Paragraphs are separated by one blank line. Paragraph lines are the only lines permitted to exceed 80 characters. R2 Every BPGP document carries a section titled AI PROMPTS, placed immediately before the Revision History. It is mandatory and always present. It holds at least one copy-paste prompt that would regenerate this document with fresh content. R3 Every line that is NOT a body paragraph is 80 characters or fewer. This includes headings, separators, tables, lists, control blocks, and prompt blocks. Tables that do not fit must be restructured. ================================================================================ 1. PURPOSE AND SCOPE ================================================================================ 1.1 WHAT THIS STANDARD IS This document is the single, comprehensive style definition for the Daralbeida BPGP (Business Plan / General Purpose) plain-text document format. It is the controlling reference for every principal, contractor, and AI system producing documents tagged Style: BPGP. It consolidates and supersedes the four BPGP-related files listed in the header Related Docs field. This standard is itself written in BPGP format. It both defines the format and demonstrates it. A reader can study the rules in Sections 3 through 15 and verify those rules by inspecting the surrounding structure of this very file. 1.2 WHAT BPGP COVERS BPGP applies to every internal Daralbeida plain-text operational document, including but not limited to Standard Operating Procedures, knowledge base entries, intelligence reports, market and business intelligence syntheses, operational briefs, compliance references, master plans, reference files, and standards documents such as this one. It applies to any plain-text document the company is responsible for that may be acted upon, distributed internally, or shared with onboarded contractors and AI systems. 1.3 WHAT BPGP DOES NOT COVER BPGP does not govern HTML deliverables, branded visual documents, spreadsheet workbooks, word-processor files, presentation files, or the public-facing business plan, which uses its own HTML visual format. Those formats have separate specifications and must not be coerced into BPGP shape. 1.4 DEFAULT APPLICATION Any document produced for Daralbeida in plain-text format that lacks an explicit, controlling style specification defaults to BPGP. The author may not invent a private format for a plain-text operational document. 1.5 RELATION TO THE VIEWER PARSER The Daralbeida internal site at daralbeida.com (via the /_devt/ and /_prod/ mirrors) carries a purpose-built plain-text viewer that renders BPGP files with branded typography, section navigation, and entity-coloured theming. Several formatting rules in this standard are parser contracts: the viewer reads the .txt file and uses those exact patterns to recognise headings, tables, lists, sub-labels, template blocks, and the Document Control footer. A deviation is not an aesthetic problem; it is a rendering failure visible to every reader of that document. Sections marked Parser Contract in this standard must be followed verbatim or the renderer will fall back to plain body text for the affected element. 1.6 CONSOLIDATION NOTE Version 3.0 consolidated four prior BPGP-related files: the COMM v2.2 standard (DARX_COMM_BPGP_202605292130.txt), the OPS v2.1 standard (DARX_OPS_BPGP_V2_20260523.txt), the OPS v1.0 standard (DARX_OPS_BPGP_20260501.txt), and the OPS Prompts v1.0 file (DARX_OPS_PROMPTS_BPGP_20260525.txt). Where the prior files disagreed, that standard resolved the conflict explicitly in favour of the most recent, parser-correct rule. Version 3.1 was first issued on 2026-05-30 as a delta-only document (DARH_STDS_BPGP_202605301215.txt) that formalised the Glossary block and the Acronym block, added parser regex contracts for both, and documented the ACRONYM_EXCEPTIONS list used by the inline auto-boxer. This issue folds the v3.1 delta into v3.0 to produce a single standalone v3.1 standard. From this issue onward, the v3.0 base file and the v3.1 delta file are both SUPERSEDED. A reader needs only this file to understand and produce v3.1 BPGP documents. v3.1 introduces no rule changes outside the Glossary and Acronym block specifications and the inline acronym auto-boxer. All v3.0 documents that already use the indented Acronym layout and the indented em-dash Glossary layout remain conforming without modification. The Revision History in Section 16 records the v3.0 base, the v3.1 delta, and this consolidation event. ================================================================================ 2. WHAT BPGP IS AND THE FOUR CORE OBLIGATIONS ================================================================================ 2.1 DEFINITION BPGP, the Business Plan / General Purpose format, is Daralbeida's plain-text document standard. Documents in this format are readable in any plain-text environment, including terminals, plain editors, email bodies, and printed pages, without loss of structure or meaning. They require no rendering engine, no stylesheet, and no font. When opened in the Daralbeida viewer they render with full branded typography; when opened anywhere else they remain fully usable as structured plain text. The four core obligations of every BPGP document are stated in Sections 2.2 through 2.5. They are not aspirational; they are conformance requirements. 2.2 COMPLETENESS Every required section must be present. A document missing the AI Prompts section, the Revision History, the Acronyms section, the Glossary section, the Document Control footer, or the END OF DOCUMENT line is non-compliant regardless of how well the content sections are written. A short document that omits required sections is a failed document; a long document that contains all required sections correctly is a compliant document. 2.3 CONSISTENCY Section numbering, divider style, indentation depth, field labels, and field formats must be identical throughout the document and consistent with this standard. A document that introduces its own indentation rule, its own field label, or its own divider style for a single section is non-compliant. 2.4 PRECISION Claims, thresholds, dates, identifiers, file names, and field values must be exact. Approximations belong in narrative prose only when no exact figure is available, and must be flagged as approximations in the prose. A discrepancy between a value in a table and the same value in a Glossary entry is a compliance failure. 2.5 STANDALONE OPERABILITY A reader with no prior access to any other Daralbeida document must be able to understand and act on the document using only its own contents, including the Acronyms and Glossary sections. References to other documents identify those documents by Document ID and, where useful, by file name, so the reader can locate them; they do not silently assume the reader has read them. 2.6 BREVITY IS NOT A GOAL BPGP is not a minimalist format. Brevity is not a virtue. Completeness is. Where a section's purpose calls for thoroughness, the section is thorough. Where it calls for compactness, the section is compact. Document length is set by the subject matter, not by an external word count. ================================================================================ 3. THE THREE FORMATTING RULES (R1, R2, R3) ================================================================================ 3.1 R1, SINGLE-LINE PARAGRAPHS A body paragraph is a single unbroken line. It contains no internal line breaks. Consecutive paragraphs are separated by exactly one blank line. Paragraph lines are the only lines in a BPGP document permitted to exceed 80 characters, because they are never wrapped by the author; the reader's editor or the viewer's renderer wraps them at display time. R1 makes the format diff-friendly, version-control friendly, and search-friendly, because a single conceptual unit always lives on a single addressable line. R1 does NOT apply to lists, tables, headings, sub-labels, control blocks, prompt blocks, or any other structured non-paragraph line. Those lines are governed by R3. 3.2 R2, MANDATORY AI PROMPTS SECTION Every BPGP document carries a section titled AI PROMPTS. The section is mandatory and is always present, even when no other content exists for it. It contains at least one copy-paste prompt that, pasted into an AI chat with no other context, would regenerate the document with fresh content. The section is placed immediately before the Revision History (Section 16 in this standard) and after the last operational content section. Detailed rules for the AI Prompts section are in Section 15. R2 ensures that every BPGP document is reproducible: if the source content is lost, corrupted, or needs refresh, the regeneration prompt produces a structurally compliant replacement. 3.3 R3, 80-CHARACTER NON-PARAGRAPH LIMIT Every line that is not a body paragraph must be 80 characters or fewer. This covers headings, the 80-equals and 80-hyphen separator lines, table rows, list items, control block lines, prompt block lines, and code block contents if any. Section separator lines (the 80 equals signs and the 80 hyphens) run to EXACTLY 80 characters, not 79 and not 81. A table that cannot fit within 80 characters must be restructured: stacked into more rows, abbreviated, or split into two tables. The combination of R1 and R3 is deliberate. R1 lets paragraph content flow freely without the author counting characters. R3 forces every structural element into a known width so the document renders predictably in any 80-column terminal and so the viewer parser can read it deterministically. ================================================================================ 4. DOCUMENT ANATOMY, REQUIRED SECTIONS IN ORDER ================================================================================ 4.1 POSITION-BY-POSITION LAYOUT Every BPGP document contains the following structural elements in the following order. No element may be omitted. No element may be reordered. Position Element Notes ──────── ────────────────────────────────── ──────────────────────────── 1 Header Control Block See Section 5. 2 Outline See Section 6. 3 Rule Summary (optional) For standards and SOPs. 4 Numbered content sections Section 1 is Purpose and Scope. Sections 2 to N are the working content. 5 AI Prompts Mandatory. See Section 15. 6 Revision History Mandatory. See Section 16. 7 Acronyms Mandatory. See Section 17. 8 Glossary Mandatory. See Section 18. 9 Document Control Footer See Section 13. 10 END OF DOCUMENT line Exact string. See 13.5. The Outline at Position 2 must list every numbered section and sub-section, plus the Document Control trigger, with section numbers that exactly match the body. 4.2 SECTION POSITION RULES Section 1 is always titled "Purpose and Scope." It may not be renamed, reordered, or merged with another section. The AI Prompts, Revision History, Acronyms, and Glossary sections are always the final four numbered content sections, in that order, immediately before the Document Control footer. They may not be placed mid-document or in an appendix. 4.3 SECTION COUNT TARGET The target range for the number of numbered sections in a BPGP document is four to fifteen. Fewer than four is too thin to justify the structural overhead. More than fifteen degrades the viewer's bottom navigation usability because each section becomes a navigation tab. Controlling reference documents such as this standard may exceed fifteen sections when the subject matter demands it, but ordinary operational documents should remain in range. ================================================================================ 5. HEADER CONTROL BLOCK ================================================================================ 5.1 TEMPLATE The header control block is the first element of every BPGP document. It is wrapped above and below in lines of exactly 80 hyphens. Inside, each field is one line of the form LABEL : VALUE. The label is left-justified in a 16-character field; then a colon; then one space; then the value. Long values continue on the next line, indented 18 spaces, so the continuation text aligns under the value column. ------------------------------------------------------------------------------ DOCUMENT CONTROL (HEADER) ------------------------------------------------------------------------------ Document ID : [DARX_DEPT_TYPE_NNN] Title : [Full document title] Version : [X.X] Status : [DRAFT|IN_REVIEW|APPROVED|ACTIVE|SUPERSEDED|RETIRED] Classification : [See Section 5.5] Prepared By : [Name or role / Daralbeida] Reviewed By : [Name or role / Daralbeida] Approved By : [Name or role / Daralbeida] Approval Date : [YYYY-MM-DD or (pending)] Owner : [Name or role / Daralbeida] Date Created : [YYYY-MM-DD] Last Revised : [YYYY-MM-DD HH:MM UTC] Update Cycle : [30 days | 60 days | 90 days | NONE] Next Review Due : [YYYY-MM-DD or NONE] Annual Review : [YYYY-MM-DD or NONE] Retention : [Period and basis] Department : [Department code, see Section 11.7] Style : BPGP Keywords : [Comma-separated retrieval terms] Related Docs : [File names of related documents, or (none)] Supersedes : [File name of the previous version, or (none)] Superseded By : [File name of the successor, or (none, current version)] ------------------------------------------------------------------------------ 5.2 REQUIRED FIELDS, IN ORDER The fields appear in the exact order listed in the template above. No field may be omitted. A field that does not yet apply (for example, Superseded By for a current document) carries an explicit placeholder such as "(none, current version)" rather than being left blank. 5.3 LABEL COLUMN WIDTH The label column is exactly 16 characters wide. This width accommodates the longest required label ("Classification") and produces a clean colon column for fast visual scanning. Authors must not adjust this width for shorter labels; the consistency of the colon column is part of the parser contract. 5.4 CONTINUATION OF LONG VALUES When a value is too long to fit on a single line within the R3 80-character limit, it continues on the next line indented by exactly 18 spaces (the 16-character label field plus the colon and the one space). The continuation has no label and no colon; it is plain text aligned under the value column. 5.5 FIELD-BY-FIELD DEFINITIONS The semantic meaning of each Document Management field, including Status lifecycle values, Update Cycle options, Next Review Due derivation, Annual Review timing, and the lineage fields, is defined in Section 12. The Section 12 definitions are the authoritative reference; the brief gloss in this section is for orientation only. Document ID, Title, Version, Status, Classification: identify and grade the document. Document ID and Title are stable across versions; Version increments at every revision; Status records the lifecycle state. Prepared By, Reviewed By, Approved By, Approval Date, Owner: record accountability. Approval Date is the date of sign-off. Date Created, Last Revised, Update Cycle, Next Review Due, Annual Review: record time discipline. Last Revised always carries date and 24-hour UTC time. Retention, Department, Style, Keywords: classify the document for storage and retrieval. Style is always BPGP for documents under this standard. Related Docs, Supersedes, Superseded By: record lineage. All three name files by file name, not by Document ID. ================================================================================ 6. OUTLINE BLOCK ================================================================================ 6.1 POSITION AND MARKERS The Outline block appears immediately after the closing 80-hyphen line of the header control block. It is introduced by the bare word OUTLINE on its own line, followed by a line of exactly 80 hyphens, followed by a blank line, followed by the outline body. The outline body is followed by a blank line, then a closing line of exactly 80 hyphens, then a blank line, before the Rule Summary or the first section heading. 6.2 OUTLINE FORMATTING RULES Top-level section entries are indented two spaces, then the section number, then a period, then two spaces, then the section title. Sub-section entries are indented nine spaces, then the decimal number (for example 4.2), then two spaces, then the sub-section title. Sub-sub-section entries are indented fifteen spaces, then the three-level decimal number (for example 4.2.1), then two spaces, then the title. No trailing punctuation appears on outline entries. Outline entries must exactly match the section titles as they appear in the document body. Paraphrasing is forbidden. If a section title changes during revision, the outline entry is updated in the same revision. 6.3 SUB-SECTION AND SUB-SUB-SECTION ENTRIES The Outline lists every sub-section and every sub-sub-section, not only the top-level sections. This is mandatory for controlling reference documents such as this one. Operational documents with few sub-sections still list them for completeness; the resulting outline aids navigation in raw text and reproducibility of the document. 6.4 FIRST-WORD RULE, VIEWER NAVIGATION The Daralbeida viewer renders a bottom navigation bar with one tab per top-level section. The tab text is the first word of the section title, truncated as needed. Authors must therefore plan section titles so that the first word is a meaningful standalone label of ten characters or fewer, in plain alphabetic characters, with no trailing punctuation. Articles such as "The," "A," and "An," and interrogatives such as "What," "How," and "Why," are not acceptable first words for a numbered section. Good : 4. QUALIFICATION REQUIREMENTS nav: Qualification Good : 7. COMPLIANCE OBLIGATIONS nav: Compliance Poor : 4. WHAT REQUIREMENTS MEAN nav: What Poor : 7. NAMING, IDS AND CODES nav: Naming, 6.5 OUTLINE EXAMPLE The Outline block at the top of this document is the canonical example. It uses the indentation, numbering, and entry style required by this section. ================================================================================ 7. SECTION STRUCTURE ================================================================================ 7.1 TOP-LEVEL HEADINGS, BAR-TITLE-BAR PARSER CONTRACT Every top-level numbered section uses an exact three-line pattern called Bar-Title-Bar. There are no blank lines between the bars and the title. There are no exceptions. ============================================================================== N. SECTION TITLE IN ALL CAPS ============================================================================== The N is a positive decimal integer, written without leading zeros. Roman numerals and letters are not permitted as section numbers. The title is in ALL CAPS. The section number is followed by a period and one space before the title. One blank line separates the closing 80-equals line from the first content line of the section. A section heading that lacks the bar above it, or lacks the bar below it, is not recognised by the viewer parser and renders as plain body text. 7.2 SUB-SECTION HEADINGS Sub-sections use decimal numbering (for example 7.1, 7.2). The heading is a single line of the form N.N then two spaces then the sub-section title in ALL CAPS, with no leading and no trailing decorative characters. The heading line is followed by exactly one blank line, then the content. The viewer renders recognised sub-section headings as styled second-level elements. Any lowercase letter in the heading line disqualifies the line from sub-section recognition, and it renders as body text instead. Authors must verify ALL CAPS in every sub-section heading before publication. 7.3 SUB-SUB-SECTION HEADINGS Sub-sub-sections use three-level decimal numbering (for example 7.1.1). The heading is a single line of the form N.N.N then two spaces then the title in Title Case (initial caps on principal words). The heading is followed by exactly one blank line. The viewer does not render sub-sub-section headings as styled elements; they exist for raw-text navigation only. Use sub-sub-sections sparingly; if a sub-section needs more than three sub-sub-sections, the underlying material usually wants restructuring into a proper sub-section of its own. 7.4 SECTION NUMBERING RULES Numbering is continuous and sequential from 1 through the final numbered section. Numbers must not be skipped, reused, or rearranged across revisions; if a section is removed, the remaining sections are renumbered, the Outline is updated, and the renumbering is noted in the Revision History. The AI Prompts, Revision History, Acronyms, and Glossary sections are always the last four numbered sections, in that order. Document Control is the footer block, not a numbered section, but it appears in the Outline as DOCUMENT CONTROL (FOOTER). ================================================================================ 8. BODY TEXT RULES ================================================================================ 8.1 SINGLE-LINE PARAGRAPHS, R1 IN PRACTICE R1 governs body paragraphs. In practice this means the author writes a paragraph without inserting Enter keystrokes inside it; only at the end of the paragraph is a single newline used, followed by a blank line, then the next paragraph as another single line. The author does not wrap text at any column. This is the only kind of line in the document permitted to exceed 80 characters. The author may keep paragraphs short when the subject lends itself to short paragraphs. The discipline is one paragraph per line, not paragraphs of any particular length. 8.2 VOICE, TENSE, AND CASE Use the active voice wherever the actor is known. Use the present tense for statements of rule and the past tense for records of prior events. Use sentence case in prose; ALL CAPS is reserved for headings and labels. 8.3 PARAGRAPH SPACING One blank line separates paragraphs within a section. Two blank lines separate the final content line of a section from the next section heading. The Bar-Title-Bar pattern itself contributes blank lines that the author counts as part of the two-line gap. 8.4 INDENTATION LEVELS Body paragraphs are flush left. Tabular content, list items, and continuation lines are indented as follows: Level Spaces Use ───── ────── ────────────────────────────────────────────────────── 0 0 Section headings, body paragraphs 1 2 First-level list items, table content, sub-block labels 2 4 Sub-items beneath first-level list items 3 6 Sub-sub-items (rare; restructure if possible) - 18 Continuation of a long header-block value Spaces only. Tab characters must not appear anywhere in the file. 8.5 NUMBERS IN PROSE Numbers, thresholds, financial figures, and percentages belong in tables when a table is available. When a number must appear inside a paragraph (for example, a legal threshold cited in passing), it is written as a numeral with its unit, not spelled out: "the IOC ceiling is 0.8% FFA," not "zero point eight percent." 8.6 DATE FORMATS Dates are written in three distinct formats depending on context: Context Format Example ──────── ────────────────── ────────────────── Field YYYY-MM-DD 2026-05-30 Date+time YYYY-MM-DD HH:MM UTC 2026-05-30 07:24 UTC Prose Month D, YYYY May 30, 2026 File name YYYYMMDDHHMM 202605300724 The Last Revised header field and the corresponding file name token are always in UTC and always carry the same instant; if one changes, the other changes in the same revision. 8.7 CROSS-REFERENCES Reference other sections by number: "See Section 4.2." Do not reference sections by title alone, because titles may evolve between versions. Reference other documents by Document ID, and where helpful also by file name: "See DARX_OPS_BPGP_001 in file DARX_OPS_BPGP_V2_20260523.txt." Document IDs are stable across versions; file names are not. ================================================================================ 9. TABLE, LIST, AND SPECIAL BLOCK FORMATTING ================================================================================ 9.1 TABLES, STRUCTURE Tables are the primary vehicle for numerical data, comparisons, thresholds, and structured reference. They are introduced by a label line or by the preceding sentence; a table never drops into the text without an introduction. Column headers are written in Title Case on a single header row. Data rows follow one per line, with values padded with spaces so columns align to a consistent left margin. A blank line precedes the table and a blank line follows it. 9.2 TABLES, THE BOX-DRAWING SEPARATOR PARSER CONTRACT The separator line that sits between the header row and the data rows must use the Unicode box-drawing character horizontal bar, U+2500 (the character that looks like a long thin dash). The ASCII hyphen is NOT recognised by the viewer parser as a table column separator. A table whose separator is drawn with ASCII hyphens renders in the viewer as plain body text with no columns, no alignment, and no styling. The Unicode character is a parser contract, not an aesthetic choice. The separator line spans the full width of the table, never exceeding 80 characters under R3. Within the separator, a run of U+2500 characters underlines each column, and runs are separated by at least two spaces matching the column gutter. 9.3 TABLES, COLUMN ALIGNMENT RULES Columns are space-aligned. All values in a column align to the same left margin. A minimum of two spaces separates adjacent columns. Vertical pipe characters (|) and box-drawing junction characters must not appear in BPGP tables; BPGP tables are space-aligned, not box-drawn. 9.4 TABLES, NULL CELLS AND WIDTH CONSTRAINT Null or not-applicable cells display a single hyphen (-) or "N/A". Cells must not be left blank, because a blank cell creates alignment ambiguity. Every table row fits within 80 characters under R3; a wide table is restructured by stacking rows, abbreviating headers, or splitting into two tables. 9.5 LISTS, UNORDERED Unordered list items use a hyphen-space prefix at the appropriate indent. The hyphen-space pattern is a parser contract: the asterisk and the Unicode bullet character render literally as text and are not recognised. Continuation lines for the same item indent four or more spaces under the item text. Sub-items indent a further two spaces and use a second hyphen-space. - First item, possibly with a long line that the reader will scan. - Sub-item A. - Sub-item B. - Second item. 9.6 LISTS, ORDERED AND LETTERED Sequential procedural steps use numeric ordering, "1." "2." "3." with two spaces after the period: 1. First step. 2. Second step. Non-sequential but labelled items use parenthesised lowercase letters: (a) First item. (b) Second item. 9.7 LISTS, RULES AND PROHIBITED MARKERS A list is introduced by a colon on the preceding line or by a full sentence ending in a colon. Do not drop a list without an introduction. Do not mix ordered and unordered styles within a single list. Lists of more than eight items should be restructured as a table or split into sub-lists with labels. Prohibited list markers: the asterisk (*) and the Unicode bullet character (the round dot). Both render literally in the viewer because the parser does not recognise them. The hyphen-space pattern in 9.5 is the only recognised unordered list trigger. 9.8 SUB-LABEL BLOCK, UPPERCASE PLUS COLON A sub-label is a line that begins with an uppercase letter, ends with a colon, contains no other content, and is fewer than fifty characters long. The viewer renders it as a styled uppercase label above the following content. Use sub-labels to introduce small inline blocks within a section without claiming a sub-section number. Decision criteria: ... content for the decision criteria block ... 9.9 TEMPLATE BLOCK, QUOTE WITH GOLD BORDER A template block begins with a line of the form "Template, [topic]" (a literal word "Template" then a comma, then the topic). The lines that follow are rendered by the viewer as a styled quotation with a gold left border. Use template blocks for sample email subjects, sample messages, and other small literal content that the reader is expected to copy and adapt. Template, Email subject line Body content rendered as a styled quotation. 9.10 HORIZONTAL RULE INSIDE A SECTION A line consisting of five or more ASCII hyphens, on its own, acts as a visual horizontal rule inside a section without starting a new section or sub-section. Use sparingly to separate distinct phases inside a long section. 9.11 ACRONYM BLOCK, FORMAL DEFINITION (FORM A AND FORM B) An Acronym block is a section of a BPGP document whose section title (case-insensitive) contains the substring "acronym". The viewer parser identifies such a section by that heuristic and attempts to read each non-blank line inside the section as an acronym entry. Two layouts are formally valid as of v3.1: Form A (indented) and Form B (flush-left). A given Acronym block uses one form throughout; mixing Form A and Form B inside the same block is prohibited. FORM A, INDENTED CODE PLUS DEFINITION This is the canonical and historically preferred layout. Used throughout v3.0 documents. Every entry follows the pattern: Pattern: [indent of two or more spaces]CODE[two or more spaces]Definition Rules: a. The line is indented by at least two spaces from column zero. b. The code is one to twelve characters: letters, digits, slash, hyphen, underscore, period, plus. c. Two or more spaces separate the code from the definition. This gap is the parser's column delimiter; a single space is not sufficient. d. The definition continues to end of line. e. A definition that wraps onto a continuation line MUST indent that continuation line to at least the start of the definition column. The parser appends sufficiently-indented continuation lines to the most recent entry. Parser contract regex (JavaScript syntax): /^\s+([A-Za-z][A-Za-z0-9\/\-_.+]{0,11})\s{2,}(\S.*)$/ Example: BI Business Intelligence EVOO Extra Virgin Olive Oil ACoS Advertising Cost of Sale FORM B, FLUSH-LEFT CODE PLUS DEFINITION Accepted as of v3.1. Used in shorter documents where the visual weight of indentation is unwanted. Every entry follows the pattern: Pattern: CODE[two or more spaces]Definition Rules: a. The line is flush-left at column zero with no leading whitespace. b. The code MUST be uppercase letters and digits only. This disambiguator prevents flush-left Title-Case prose paragraphs from being mis-parsed as acronym rows. c. The remaining rules from Form A apply: one to twelve character code, two or more spaces separator, definition to end of line, wrapped continuation lines indented. Parser contract regex (JavaScript syntax): /^([A-Z][A-Z0-9\/\-_.+]{0,11})\s{2,}(\S.*)$/ Example: BI Business Intelligence EVOO Extra Virgin Olive Oil CODE COLUMN WIDTH When multiple entries appear in the same block, authors SHOULD pad the gap between code and definition so that the definition column is vertically aligned. The width of the code column is the longest code in the block plus at least two trailing spaces. The parser does not enforce alignment, but readers benefit from it. HEADER ROW IS PROHIBITED A header row "ACRONYM[gap]Definition" or "CODE[gap]Definition" MUST NOT appear inside an Acronym block. The parser explicitly skips any row whose code position holds the literal string "ACRONYM"; authors should remove such rows rather than rely on the skip. FORBIDDEN PATTERNS INSIDE AN ACRONYM BLOCK a. Lower-case codes in Form B. Acronyms by definition are uppercase tokens; lowercase codes belong in a Glossary block, not here. b. Multi-line stacked layout (code on one line, definition on the next). The parser only recognises stacked layout in Glossary blocks. A long definition wraps onto an indented continuation line, not onto a new entry. c. Mixed Form A and Form B inside a single block. Choose one form for the whole Acronym section. d. Em-dash separators. The em-dash is reserved for Glossary Form A; acronyms use space-gap separated columns. 9.12 GLOSSARY BLOCK, FORMAL DEFINITION (FORM A AND FORM B) A Glossary block is a section of a BPGP document whose section title (case-insensitive) contains the substring "glossar". The viewer parser identifies such a section by that heuristic and attempts to read its contents as a list of term-and-definition entries. Two layouts are formally valid as of v3.1: Form A (inline em-dash, compact) and Form B (stacked term and indented definition). Unlike Acronym blocks, Form A and Form B MAY be mixed inside a single Glossary block provided each entry independently obeys its chosen form's rules. MOTIVATION Glossary content is structurally distinct from running prose. Each entry is one term plus one definition, and the reader benefits when the viewer renders the pair as a two-column row with the term presented as a labelled chip. The parser must therefore detect each entry deterministically. v3.1 specifies the two valid Glossary layouts so that every author and every AI generating BPGP content produces parser-detectable output. FORM A, INLINE EM-DASH The compact one-line-per-entry layout. Preferred when the definition fits comfortably on a single wrapped line in the source file. Pattern: [indent of two spaces]Term — Definition Rules: a. The line is indented by exactly two spaces from column zero. b. The term is the substring from the first non-space character up to the em-dash separator. c. The em-dash U+2014 is surrounded by exactly one space on each side. d. The definition follows the em-dash and continues to end of line. e. The definition may wrap onto continuation lines. Each continuation line is indented to at least two spaces beyond the term-line indent. The parser appends continuation lines to the previous definition, joining with a single space. f. The em-dash MUST be the canonical Unicode em-dash U+2014. ASCII double-hyphen (--) and the en-dash U+2013 are NOT accepted; the parser will not detect them, and the entry will render as plain paragraph text. Parser contract regex (JavaScript syntax): /^\s+(\S[^\u2014]{0,80}?)\s+\u2014\s+(.+)$/ Example: Backup Supplier — A producer qualified to DAB_SOP_SOURCING_001 BACKUP tier. Provides supply continuity if the PRIMARY supplier cannot fulfill an order. FORM B, STACKED TERM AND INDENTED DEFINITION The long-form layout. Preferred when the definition runs paragraph-length, when the Glossary is the dominant content of the section, or when the document's authorial voice benefits from each term being typographically separated from its definition. Pattern: Term Definition body, indented by four spaces, wrapping over one or more lines as needed. Rules: a. The term is on a line by itself, FLUSH-LEFT at column zero with no leading whitespace at all. b. The term line is in Title Case. It contains one to six words. It carries no trailing punctuation other than an internal hyphen (e.g. "Single-Supplier Dependency"). c. The definition begins on the next line, indented by exactly four spaces. d. The definition body may wrap to additional lines, each indented by the same four spaces. e. The entry ends at the first BLANK line, or at the first flush- left line that follows the indented definition body, whichever comes first. The parser joins all definition lines with one space. f. A blank line MUST separate one entry from the next. Parser detection (lookahead algorithm, applied when the section title matches /glossar/i): tryStackedGlossaryAt(idx): a. Line at idx must be flush-left (no leading whitespace). b. Line must be one to sixty characters. c. Line must NOT end in '.', ';', or ':'. d. Line must NOT be entirely uppercase (those are sub-labels). e. Line must NOT be entirely lowercase. f. Line must NOT match a header-field key:value pattern. g. The next line (idx + 1) must exist, be indented, and have content. h. Walk forward from idx + 1, gathering every indented line with content, until a blank line or a flush-left line is reached. i. Join collected indented lines with one space; push as the definition body of an entry whose term is the line at idx. j. Return the count of consumed lines so the caller may advance. Example: Concentration Risk The risk arising from reliance on a single supplier, customer, or geographic source. In the Daralbeida context, operating with only one qualified PRIMARY producer and no contracted BACKUP creates concentration risk that must be disclosed to investors if it persists through Year 1. WHICH FORM TO CHOOSE Use Form A when the definition is one or two sentences and fits within roughly 200 to 280 characters. Use Form B when the definition runs longer, when the Glossary is the dominant content of the section, or when the document benefits from the term being typographically separated from its definition. TERM STYLE Terms are Title Case. The first letter of each significant word is uppercase; minor words (a, an, the, of, and, in, on, for, to) are lowercase when they appear inside a multi-word term, except when they begin the term. Acronyms that ARE the term (e.g. "EVOO") may be presented in their natural uppercase. Terms MUST NOT end with sentence-ending punctuation. Terms MAY include internal hyphens and the apostrophe-s genitive. Terms MUST NOT include parentheses or trailing notes; place synonyms or qualifiers in the definition body, not in the term line. DEFINITION STYLE Definitions are complete sentences. They begin with a capital letter and end with a period (or, rarely, a question mark). They are written in present tense, third person ("provides", "creates", "defines"). They may reference other Document IDs and named sections by the rules in Section 8.7. They MUST NOT contain internal line breaks in their final rendered form; line wrapping in the source is permitted, but the parser collapses each wrap into one paragraph. ENTRY SEPARATION Entries are separated by exactly one blank line. This rule applies whether the entries use Form A, Form B, or a mix of both. The parser treats two or more consecutive blank lines as equivalent to one separator, but authors SHOULD use exactly one blank line for consistency. FORBIDDEN PATTERNS INSIDE A GLOSSARY BLOCK The following constructs MUST NOT appear inside a Glossary block: a. Bullet lists, numbered lists, or lettered lists. The Glossary IS the list; do not nest a second list structure inside it. b. Sub-labels (uppercase-plus-colon banner lines). The Glossary is a flat list; sub-banners visually break the parser's row-by-row reading. c. Tables. If tabular data is needed, lift it into its own section outside the Glossary. d. Sub-section headings (X.Y numbered headings). A Glossary is a single flat structure; sub-section headings start a new sub- section in the parser and would terminate the block prematurely. e. A header row labelled "Term" or "Definition". The Glossary needs no header row. 9.13 INLINE ACRONYM AUTO-BOXING, ACRONYM_EXCEPTIONS Inline acronym auto-boxing is a viewer feature, not an authoring rule. The viewer scans body text for runs of two or more uppercase letters and wraps each as a styled acronym chip when at least one neighbour word contains a lowercase letter (the "real prose" filter). This produces a labelled chip in the rendered output that links to the document's Acronyms section when applicable. Certain all-caps tokens are NOT acronyms in this sense and must not be chip-wrapped. v3.1 documents the exception list (ACRONYM_EXCEPTIONS) that the viewer carries to prevent corporate suffixes and similar all-caps tokens from being chip-wrapped inside brand names and prose. The list is stored in the viewer source file darx_txt_vwr.php near the top of the IIFE. Default exception set, uppercase membership, case-insensitive lookup: Anglo company suffixes: LLC, LLP, LP, PLLC, INC, CORP, CO, LTD, PLC France, Maroc, Belgium, Luxembourg company suffixes: SARL, SAS, SASU, SA, SCI, SCS, SNC, EURL, SCA, SCP DACH region company suffixes: GMBH, AG, KG, OHG, UG, GBR Benelux company suffixes: BV, NV, CV, VOF Iberian and Italian company suffixes: SL, SLU, SLNE, SPA, SRL, SAPA, SCRL Nordic and Baltic company suffixes: AB, ASA, APS, OY, OYJ, AS Asian company suffixes: KK, YK, PVT, PTE, BHD, SDN Country and region codes seen naked in prose: US, USA, UK, EU, UAE, KSA, MA Currency codes seen naked in prose: USD, EUR, GBP, MAD, AED, CHF, JPY, CNY Other doubled-letter common words: OK Authors and AI agents MAY request additions to this list by raising the proposal to the parser maintainer. Adding an entity that is itself an acronym worth chip-wrapping (for example a department code) to ACRONYM_EXCEPTIONS would defeat the auto-boxer for that token; the list is intentionally restricted to tokens whose chip-wrapping would be a defect. ================================================================================ 10. PROHIBITED ELEMENTS ================================================================================ 10.1 MARKUP OF ANY KIND Markdown, HTML, bold, italic, underline, struck-through, and decorative quoting are prohibited. The viewer does not render any of them. The author obtains emphasis by structural means: a sub-heading, a sub-label, a table, or a re-ordered sentence that leads with the important content. 10.2 BULLET SYMBOLS The asterisk, the bullet (U+2022), and other dot-style bullet characters are prohibited as list markers. The only recognised unordered list marker is the hyphen-space pattern (Section 9.5). 10.3 HYPHEN IN NAMES OR DOCUMENT IDS Hyphens are prohibited in file names and in Document IDs. Underscores are the only token separator in both contexts. Hyphens remain available in ordinary prose, in the Bar-Title-Bar parser pattern itself (the 80-hyphen rule for the header/footer wrapping), and as the horizontal-rule trigger of Section 9.10. In a name or ID, a hyphen is always a defect. 10.4 LINE BREAKS INSIDE A PARAGRAPH A line break inside a body paragraph violates R1 and is prohibited. The author writes each paragraph as one unbroken line, regardless of its display width. 10.5 NON-PARAGRAPH LINES OVER 80 CHARACTERS Any line that is not a body paragraph and exceeds 80 characters violates R3 and is prohibited. Tables are restructured, prompt blocks are reformatted, headings are shortened. There is no exception. 10.6 ASCII HYPHEN AS A TABLE COLUMN SEPARATOR The ASCII hyphen as a table column separator is prohibited because the viewer parser does not recognise it; the table renders as plain text. The recognised separator is the U+2500 box-drawing horizontal bar, per Section 9.2. 10.7 DECORATIVE OR NON-FUNCTIONAL CHARACTERS Decorative characters such as em-spaces, smart quotes, ornamental dingbats, and Unicode dingbat-style separators are prohibited. The functional Unicode characters used by parser contracts are permitted because they carry semantic meaning, not because they are decorative. The currently recognised functional Unicode characters are: U+2500 (box-drawing horizontal bar) for table column separators, and U+2014 (em-dash) for Glossary Form A entry separators (see Section 9.12). Use of an em-dash anywhere else in body text is decorative and remains prohibited. ================================================================================ 11. NAMING CONVENTIONS ================================================================================ 11.1 FILE NAMING, CURRENT CONVENTION File names follow this pattern, ALL lowercase extension, underscores only: [ENTITY]_[CATEGORY]_[DESCRIPTOR]_[YYYYMMDDHHMM].[ext] Field Definition ───────────── ───────────────────────────────────────────────────────── ENTITY Entity prefix, see Section 11.2. First token. CATEGORY Category code, see Section 11.3. Drives directory placement in the viewer via the section map. DESCRIPTOR Topic descriptor in ALL CAPS, words joined by underscores. A version token such as V2 may be included when more than one named version of the same descriptor is retained. YYYYMMDDHHMM Date and 24-hour UTC time of creation or last significant revision, concatenated with no separator between them. Always 12 digits. Always UTC. ext File extension in lowercase, such as txt or html. Rules: a. The entity prefix is first. The date plus time is last. b. There is no leading date prefix and no trailing sequential number. c. The extension is lowercase. d. Underscores separate tokens. Hyphens, spaces, and dots in the name body are prohibited. e. The category code must be one of the codes in Section 11.3. f. Each significant revision RENAMES the file: the new YYYYMMDDHHMM stamp matches the new Last Revised value in the header block. Examples: DARX_BI_KBI_DASHBOARD_202605011030.html DARX_COMM_BPGP_202605292130.txt DARH_STDS_BPGP_202605300724.txt DARX_OPS_SOURCING_SOP_202605251715.txt 11.2 ENTITY CODES Code Entity Notes ───── ─────────────────────────── ────────────────────────────────── DARX Daralbeida Brands LLC Primary brand and document entity DARH Daralbeida Holdings LLC Group-level holdings entity DARM Daralbeida Maroc SARL Moroccan operating entity Every file name begins with one of these three entity codes. Documents that apply across all three entities (such as this standard) carry the DARH entity code by default because the holdings entity is the umbrella under which the brands and the operating entity sit. 11.3 CATEGORY CODES The category code is the second token of every file name. It both labels the document and determines which section page lists the file in the viewer's directory. Code Category ────── ──────────────────────────────────────────── ADD Business plan additions AMZ Amazon and e-commerce BI Business intelligence and market research BRAND Brand and design COMM Communications and documentation FIN Financial models KB Knowledge base LAUNCH Launch planning LEG Legal MI Management information MKTG Marketing OPS Operations, SOPs, and logistics PROD Product QC Quality control STDS Standards and controlling references (incl. this document) STRAT Strategy and business plan TECH Technology and web or systems documentation TOOL Tools and utilities The STDS category is introduced by this consolidated standard. Standards documents that govern other documents (such as this BPGP standard) carry STDS as their category. 11.4 DYNAMIC DIRECTORY PLACEMENT The web document directory at /_devt/01/ lists files on section pages automatically. A PHP scanner reads each file name, extracts the category token, and looks up the category in a category-to-section map. The file then appears on the mapped section page. A category that is not present in the map falls back to the Appendix section. a. The source of truth for the mapping is darx_section_map.php at the project root of the active mirror. b. To move every file of a category to a different section, change the mapped section number in that file. No file renaming is required. c. Adding a new category requires adding it to the map before files using it will appear on an intended section page. This dynamic placement is why the category token is mandatory and why it must be drawn from the published list in Section 11.3. 11.5 LEGACY FILE NAMING CONVENTIONS, SUPERSEDED Two earlier conventions are recorded here to support the interpretation of older files. Neither convention may be used for new files. Legacy convention A, date-first with sequential suffix: YYYYMMDD_[ORG]_[DEPT]_[TOPIC]_[NNN].TXT Example: 20260501_DARX_OPS_BPGP_001.TXT Legacy convention B, entity-first with 8-digit date and no time: [ENTITY]_[CATEGORY]_[DESCRIPTOR]_[YYYYMMDD].[ext] Example: DARX_OPS_BPGP_V2_20260523.txt The current convention in Section 11.1 places the entity first, uses a 12-digit YYYYMMDDHHMM stamp, uses a lowercase extension, and carries no sequential suffix. Files under legacy convention A are renamed when revised. Files under legacy convention B may keep the 8-digit stamp until their next significant revision; both 8-digit and 12-digit stamps are accepted by the current viewer scanner. 11.6 DOCUMENT ID CONVENTION Every BPGP document carries a Document ID in the header and footer control blocks. The Document ID is distinct from the file name. It uses underscores only and follows this format: DARX_[DEPT]_[TYPE]_[NNN] Field Definition ───── ────────────────────────────────────────────────────────── DARX Document prefix. Fixed as DARX for every Document ID, even for documents whose file-name entity is DARH or DARM. This preserves a single ID namespace across all three entities. DEPT Department code, see Section 11.7. TYPE Type code, see Section 11.8. NNN Three-digit sequential number within the DEPT and TYPE combination, zero-padded from 001. Examples: DARX_COMM_BPGP_001 DARX_OPS_SOP_017 DARH_STDS_BPGP_001 (this document) 11.7 DEPARTMENT CODES Code Department ────── ──────────────────────────────────────── AMZ Amazon and E-Commerce BI Business Intelligence COMM Communications and Documentation FIN Finance LEG Legal and Compliance MKTG Marketing and Brand OPS Operations and Logistics QC Quality Control STDS Standards (controlling references) STRAT Strategy TECH Technology and Systems 11.8 TYPE CODES Code Document Type ────── ──────────────────────────────────────── BP Business Plan section BPGP BPGP standard or controlling reference BRIEF Brief (external or contractor) KB Knowledge Base LOG Log or register REF Reference document SOP Standard Operating Procedure SPEC Specification 11.9 FILE NAME AND DOCUMENT ID ARE DISTINCT The Document ID inside the control block identifies the document across versions and is stable until the document is retired. The file name identifies the specific dated and timed file on disk and changes with every significant revision. They are distinct identifiers and must not be confused: prose cross-references cite the Document ID; file lists, related-docs fields, and links cite the file name. ================================================================================ 12. DOCUMENT MANAGEMENT FIELDS ================================================================================ 12.1 STATUS LIFECYCLE The Status field records the lifecycle state of the document. Allowed values, in normal order of progression: Status Meaning ─────────── ────────────────────────────────────────────────────────── DRAFT Being written; not yet reviewed. IN_REVIEW Submitted for review; awaiting approval. APPROVED Signed off but not yet in force as the operative version. ACTIVE Approved AND in force; the operative version. SUPERSEDED Replaced by a newer version named in Superseded By. RETIRED Withdrawn from use; retained only for the record. A document moves to APPROVED only after both Approved By and Approval Date are filled. A document moves to ACTIVE when it is the operative version for its Document ID; at any moment, at most one file for a given Document ID is ACTIVE. 12.2 APPROVAL FIELDS Approved By records the name or role of the person who signed off the document. Approval Date records the date of that sign-off as YYYY-MM-DD. Reviewed By records the name or role of the person who reviewed the document before approval; it may equal Approved By in a small team. Where review and approval have not yet occurred, the fields carry the literal value "(pending)". 12.3 DATE AND TIME FIELDS, UTC Date Created is the date the document first existed, written as YYYY-MM-DD, and never changes after the initial issue. Last Revised is the date and time of the most recent significant change, written as YYYY-MM-DD HH:MM UTC using a 24-hour clock and Coordinated Universal Time. The file name carries the same instant as YYYYMMDDHHMM with no separator; the file name and the Last Revised field always agree. 12.4 UPDATE CYCLE AND NEXT REVIEW DUE Update Cycle is the maximum interval, in days, between scheduled reviews. Allowed values are "30 days," "60 days," "90 days," and "NONE." Operationally live documents typically carry 30 or 60 days; standards and reference documents typically carry 90 days; reference documents that codify a settled subject (such as a historical chart) carry NONE. Next Review Due is the date on which the next review falls due. It is computed as the Last Revised date plus the Update Cycle in days, written as YYYY-MM-DD. When the Update Cycle is NONE, the Next Review Due is NONE. A document whose Next Review Due has passed is overdue for review and is flagged for the Owner. 12.5 ANNUAL REVIEW Annual Review is a mandatory yearly checkpoint that supplements the Update Cycle. Whenever the Update Cycle is under 365 days (that is, any of 30, 60, or 90), the document also carries an Annual Review date set to one calendar year after the Last Revised date. For example, Last Revised 2026-05-30 gives an Annual Review of 2027-05-30. The short Update Cycle drives interim updates; the Annual Review guarantees a full review at least once per year regardless of activity. When the Update Cycle is NONE, no Annual Review date is set. 12.6 LINEAGE FIELDS, SUPERSEDES AND SUPERSEDED BY Supersedes names the file that this version replaces, or "(none)" if this is the initial issue. Superseded By names the file that replaces this version, or "(none, current version)" while this remains the live version. Both fields use file names, never Document IDs, because they point at specific dated and timed files on disk. Related Docs lists other files referenced or relied upon, by file name. 12.7 KEYWORDS Keywords is a comma-separated list of retrieval terms describing the document subject. They support search across the document corpus and quick visual filtering in file listings. Authors choose Keywords that a future reader would actually type into a search box; vague terms such as "document" or "internal" are not useful. 12.8 VERSION NUMBERING Major revisions increment the integer (1.0, 2.0, 3.0). Minor revisions increment the decimal (1.1, 1.2, 1.3). A draft before first approval is Status DRAFT, Version 1.0. After approval the document moves to APPROVED at 1.0 and to ACTIVE when adopted as the operative version. A superseded document carries Status SUPERSEDED with the successor named in Superseded By. 12.9 REVIEW TRIGGERS Review Triggers is a footer-block field that states event conditions which force a review regardless of the Update Cycle. Examples: "upon any Amazon category policy update," "upon any pricing change or SKU addition," "upon a change to the LIVE FILE NAMING CONVENTION." Triggers are stated as testable conditions, not as vague calls to vigilance. 12.10 RETENTION Retention is the period for which the document is kept from the date of creation or from a stated event. Default for operational documents is three years from date of creation. Controlling reference documents and standards carry "Duration of Daralbeida operations" with superseded versions retained indefinitely in Archives. 12.11 COMPLIANCE FIELD The COMPLIANCE field is mandatory in the Document Control footer of every BPGP document. It is not a placeholder. It carries at least one substantive statement specific to the document's subject matter, namely a rule, restriction, or condition that a reader acting on the document must not violate. Acceptable COMPLIANCE statements include pre-publication confirmation requirements (for example, on pricing, names, dates), approval requirements before action is taken, restrictions on distribution or use of content, and cross-document dependencies that must be satisfied before acting. The COMPLIANCE field may NOT read "None" or "N/A." A document that cannot identify a single substantive compliance condition has not been reviewed sufficiently to be marked ACTIVE. ================================================================================ 13. DOCUMENT CONTROL FOOTER ================================================================================ 13.1 TRIGGER LINE, EXACT STRING The Document Control footer is triggered by a line containing exactly the words DOCUMENT CONTROL (FOOTER), wrapped above and below by lines of 80 hyphens. Nothing else appears on the trigger line: no parenthetical other than "(FOOTER)," no leading or trailing decorative characters, and no label such as "BLOCK" or "SECTION." Any addition to the trigger line causes the parser to fail to recognise the footer and the entire block renders as ordinary body text. 13.2 REQUIRED FIELDS The footer block recaps the live status of the document and adds disposition fields not central to the header. Fields, in order: Document ID : (must match header exactly) Version : (must match header exactly) Status : (must match header exactly) Last Revised : (must match header exactly) Update Cycle : (must match header exactly) Next Review Due : (must match header exactly) Annual Review : (must match header exactly) Owner : (must match header exactly) Distribution : (audience descriptor) Review Triggers : (event-condition list, see Section 12.9) COMPLIANCE : (substantive statement, see Section 12.11) Revision History: See Section 16 13.3 DISTRIBUTION Distribution is a free-text descriptor of the audience that may receive the document. Examples: "Internal; all principals and contractors producing BPGP documents," "Internal; PYB and US trade counsel by function only," "Internal; principals on onboarding." 13.4 REVISION HISTORY POINTER The footer's Revision History line is a one-line pointer, not the table itself. The actual table lives in Section 16. The pointer reads "See Section 16" so the reader knows where the audit trail is recorded. 13.5 END OF DOCUMENT LINE, EXACT STRING The absolute final line of every BPGP document is exactly: END OF DOCUMENT There is no suffix, no Document ID appended, no decorative characters, and no trailing blank line. The viewer uses exact string matching to terminate its parse loop; the variant "END OF DOCUMENT, [DOC ID]" does not match and the file renders with a stray paragraph at the bottom of the page. The END OF DOCUMENT line appears between two lines of 80 hyphens; it is the absolute last printable text in the file. ================================================================================ 14. PRE-PUBLICATION CHECKLIST ================================================================================ Use this checklist before a BPGP document is marked ACTIVE or distributed. 14.1 STRUCTURE CHECKLIST Item Done ────────────────────────────────────────────────────────── ──── Header control block present, all fields populated [ ] Style field reads BPGP in both header and footer [ ] Outline present, matches every section, sub-section, and [ ] sub-sub-section number and title in the body Section 1 is titled "Purpose and Scope" [ ] Sections numbered sequentially with no gaps or duplicates [ ] AI Prompts section is the fourth-from-last numbered section [ ] Revision History is the third-from-last numbered section [ ] Acronyms is the second-from-last numbered section [ ] Glossary is the last numbered section [ ] Document Control footer triggered by exact string [ ] COMPLIANCE field is not blank, "None," or "N/A" [ ] END OF DOCUMENT line present, exact string, absolute last [ ] No content follows the END OF DOCUMENT line [ ] 14.2 CONTENT CHECKLIST Item Done ────────────────────────────────────────────────────────── ──── Each body paragraph is one unbroken line (R1) [ ] No non-paragraph line exceeds 80 characters (R3) [ ] No bullet symbols, markdown, HTML, or markup of any kind [ ] Tables use U+2500 separator, not ASCII hyphen [ ] Tables fit within 80 characters (restructured if needed) [ ] Every acronym used appears in the Acronyms section [ ] Every defined term requiring explanation in the Glossary [ ] Glossary values consistent with table values in the body [ ] Cross-references cite section numbers, not titles alone [ ] Cross-references to other documents cite Document IDs [ ] All field-format dates use YYYY-MM-DD [ ] All prose dates use Month D, YYYY [ ] All file-name dates use YYYYMMDDHHMM (12 digits, UTC) [ ] 14.3 DMS FIELD CHECKLIST Item Done ────────────────────────────────────────────────────────── ──── Status is a valid lifecycle value [ ] Approved By and Approval Date filled if APPROVED or ACTIVE [ ] Last Revised carries date and 24-hour UTC time [ ] Update Cycle is one of 30, 60, 90, or NONE [ ] Next Review Due equals Last Revised plus Update Cycle [ ] Annual Review set to Last Revised plus one year when cycle is [ ] under 365 days, otherwise set to NONE Keywords field non-empty and useful for retrieval [ ] Supersedes names the previous file, or (none) [ ] Superseded By names the successor, or (none, current version) [ ] File name and Document ID use underscores only, never hyphens [ ] File name ends with date plus time as YYYYMMDDHHMM in UTC [ ] File name YYYYMMDDHHMM matches Last Revised exactly [ ] 14.4 DARALBEIDA BRAND COMPLIANCE CHECKLIST Item Done ────────────────────────────────────────────────────────── ──── Brand name is spelled "Daralbeida" (one word, no hyphen) [ ] Origin claims are "Morocco" only; no sub-regional claims [ ] unless a specific contracted and verified estate is on file Pricing references, where present: 0.5L = $26, 1L = $32 [ ] (confirm before including in any document) Founder referenced as "PYB" or "the founder," never by name [ ] US trade counsel referenced by function, never by name [ ] No geographic sub-claims (no "Atlas," "Marrakech-Safi," [ ] coordinates, or mountain ranges) until estate is verified 14.5 v3.1 GLOSSARY AND ACRONYM BLOCK CHECKLIST Item Done ────────────────────────────────────────────────────────── ──── Glossary block, if present, uses Form A or Form B per entry [ ] (Section 9.12). Mixing forms across entries is permitted provided each entry independently conforms. Glossary entries contain no bullet lists, sub-labels, tables, [ ] sub-section headings, or header rows. Glossary Form A entries use Unicode em-dash U+2014; no ASCII [ ] double-hyphen, no U+2013 en-dash. Acronym block, if present, uses Form A OR Form B (not a mix) [ ] per Section 9.11. Acronym block has no header row labelled "ACRONYM" or "CODE". [ ] Brand names containing a corporate suffix (LLC, SARL, GmbH, [ ] BV, SPA, etc.) render the suffix as plain inline text when previewed in the viewer, not as an inline acronym chip (ACRONYM_EXCEPTIONS handles this; verify on first preview). ================================================================================ 15. AI PROMPTS ================================================================================ 15.1 PURPOSE The AI Prompts section is mandatory in every BPGP document (R2). It carries at least one copy-paste prompt that, pasted into a fresh AI chat with no other context, would regenerate the document with fresh content. The section exists so that the source content of any BPGP document is reproducible: if it is lost, corrupted, or needs a refresh against new facts, the regeneration prompt produces a structurally compliant replacement. 15.2 POSITION The section is the fourth-from-last numbered section of the document, placed immediately before Revision History and immediately after the last operational content section. 15.3 RULES FOR EACH PROMPT BLOCK Each prompt is wrapped in two marker lines, START OF PROMPT and END OF PROMPT, each preceded by a line of exactly 80 equals signs. The prompt itself is laid out hierarchically: numbered or labelled steps, indented sub-points, one instruction per line. Every line inside the prompt is a non-paragraph line and stays within 80 characters under R3. 15.4 EDITABLE TOKENS Parts of the prompt that the reader edits before re-running are marked with [SQUARE_BRACKETS]. The bracketed token is in ALL CAPS and uses underscores; for example, [TOPIC], [AS_OF_DATE], [SCOPE]. The bracketed token is the only thing the reader changes before re-running; everything outside the brackets is the controlled prompt. 15.5 MULTIPLE PROMPTS A document may carry more than one prompt when this is useful, for example, a short refresh prompt and a full rebuild prompt. Each prompt has its own START OF PROMPT and END OF PROMPT markers under a labelled sub-heading. 15.6 REGENERATION PROMPT FOR THIS STANDARD ================================================================================ START OF PROMPT ================================================================================ Produce the Daralbeida BPGP Style Definition Consolidated Comprehensive Standard as a single plain-text .txt BPGP document. Edit the bracketed values below before running. Document ID : DARH_STDS_BPGP_001 New version : [NEXT_VERSION, e.g. 3.2] Date+time : [YYYYMMDDHHMM in UTC] Supersedes : [PRIOR_FILENAME, e.g. DARH_STDS_BPGP_202606020036.txt] 1. Obey BPGP v3.1 in full, and have the document obey the very rules it defines: 1a. Plain-text .txt only. No HTML, markdown, bullet symbols, or markup. 1b. Each body paragraph is ONE line with no internal line breaks; paragraphs separated by a single blank line. (R1) 1c. Every non-paragraph line (headings, separators, tables, lists, control blocks, prompt blocks) is 80 characters or fewer. (R3) 1d. File names and Document IDs use underscores only, never hyphens; the file name ends with date+time as YYYYMMDDHHMM in UTC. 1e. Table column separators use Unicode U+2500 box-drawing bar. 1f. Glossary Form A entries use Unicode U+2014 em-dash exactly. 1g. The mandatory AI Prompts section carries this regeneration prompt updated for the new version. (R2) 1h. The absolute final line is the exact string END OF DOCUMENT. 2. Include the full DOCUMENT CONTROL field set in the header block, labels left-justified in a 16-character field: 2a. Document ID, Title, Version, Status, Classification. 2b. Prepared By, Reviewed By, Approved By, Approval Date, Owner. 2c. Date Created, Last Revised (YYYY-MM-DD HH:MM UTC), Update Cycle (30, 60, 90, or NONE), Next Review Due (Last Revised + cycle), Annual Review (Last Revised + 1 year when cycle is under 365). 2d. Retention, Department, Style, Keywords, Related Docs, Supersedes, Superseded By. 3. Include these numbered sections in this order: 3a. Purpose and Scope 3b. What BPGP Is and the Four Core Obligations 3c. The Three Formatting Rules (R1, R2, R3) 3d. Document Anatomy, Required Sections in Order 3e. Header Control Block 3f. Outline Block 3g. Section Structure 3h. Body Text Rules 3i. Table, List, and Special Block Formatting (includes 9.11 Acronym Block, 9.12 Glossary Block, 9.13 Inline Acronym Auto-Boxing, ACRONYM_EXCEPTIONS) 3j. Prohibited Elements 3k. Naming Conventions 3l. Document Management Fields 3m. Document Control Footer 3n. Pre-Publication Checklist (includes 14.5 v3.1 Glossary and Acronym Block Checklist) 3o. AI Prompts (this section) 3p. Revision History (one row per version, newest last) 3q. Acronyms (alphabetical) 3r. Glossary (alphabetical, full definitions) 4. Open with a header DOCUMENT CONTROL block and close with a footer DOCUMENT CONTROL block, each wrapped in 80-hyphen rules. End the file with the exact line END OF DOCUMENT, between two 80-hyphen rules; no suffix, no Document ID appended, no trailing blank line. 5. Carry forward any rule changes requested for [NEXT_VERSION] here: [DESCRIBE_CHANGES_OR_WRITE_NONE]. ================================================================================ END OF PROMPT ================================================================================ 15.7 BPGP GENERATOR, COPY-PASTE BLOCK FOR ANY NEW DOCUMENT This sub-section carries the operational generator. It is the verbatim Section 3 copy-paste block from DARX_OPS_PROMPTS_BPGP_202605310609.txt, the v3.1 OPS prompt tool, reproduced here so this standard is fully standalone. Paste the block below into a fresh AI chat session before requesting a new BPGP document, and the AI will produce a v3.1-conforming .txt file on the first attempt. This is distinct from Section 15.6, which regenerates THIS standard at its next version; the block below regenerates ANY BPGP document of your choosing. Copy everything between the START and END marker lines. Do NOT include the marker lines themselves in what you paste. After pasting, describe the document you need: topic, purpose, audience, department, classification, and any content to include. The AI will assign the Document ID, draft the Outline, write the sections, and produce a complete file. ================================================================================ START — COPY EVERYTHING BELOW THIS LINE ================================================================================ You are producing a document for Daralbeida in BPGP format. BPGP means Business Plan / General Purpose: the Daralbeida plain-text format. A purpose-built browser viewer parses your .txt and renders it. Every rule below is a parser contract, not a style preference. A deviation is a rendering failure seen by every reader of the document. Produce plain-text .txt output only. No HTML, Markdown, bold, italic, or underline. No decorative characters except those specified below. THE THREE RULES R1. Each body paragraph is ONE unbroken line, with no internal line breaks. Separate paragraphs with a single blank line. A paragraph line is the ONLY kind of line allowed to exceed 80 characters. Do NOT hard-wrap prose at 80; write the whole paragraph on one line and let the viewer reflow it. R2. Include a section titled AI PROMPTS, placed immediately before the Revision History. It holds at least one copy-paste prompt that would regenerate the document with fresh content. R3. Every line that is NOT a body paragraph is 80 characters or fewer. This includes headings, separators, tables, lists, control blocks, and the prompt block. A table that does not fit must be restructured. HEADER CONTROL BLOCK Begin the file with an 80-hyphen rule, the line DOCUMENT CONTROL (HEADER), another 80-hyphen rule, the fields below (one per line), and a closing 80-hyphen rule. All fields are required. Document ID : ENTITY_DEPT_DESCRIPTOR_NNN Title : Full document title Version : 1.0 Status : ACTIVE Classification : A level from the classification list Prepared By : PYB / Daralbeida Reviewed By : PYB / Daralbeida Approved By : PYB / Daralbeida Approval Date : YYYY-MM-DD Owner : PYB / Daralbeida Date Created : YYYY-MM-DD Last Revised : YYYY-MM-DD HH:MM UTC Update Cycle : 90 days Next Review Due : YYYY-MM-DD Annual Review : YYYY-MM-DD Retention : Duration of Daralbeida operations Department : Department code Style : BPGP Keywords : Comma-separated keywords Related Docs : Related filenames, or (none) Supersedes : Prior filename, or (none) Superseded By : (none, current version) OUTLINE BLOCK Immediately after the header, add the label OUTLINE, an 80-hyphen rule, a blank line, the numbered section list indented two spaces, a blank line, and a closing 80-hyphen rule. List every section and sub-section with the exact titles used in the body. The viewer does not render the OUTLINE; it is for raw-text navigation. NAMING (UNDERSCORES ONLY, NEVER HYPHENS) Filename : ENTITY_CATEGORY_DESCRIPTOR_YYYYMMDDHHMM.txt (lowercase .txt). ENTITY is DARX, DARH, or DARM. The stamp is the UTC date and time of creation as twelve digits, YYYYMMDDHHMM. Doc ID : ENTITY_DEPT_DESCRIPTOR_NNN, for example DARX_OPS_SOURCING_001. The filename AND the Document ID both use underscores. Never use hyphens. SECTION HEADINGS (BAR-TITLE-BAR, EXACT) Each numbered section uses this exact three-line pattern, with no blank line between the bars and the title: [80 equals signs] N. SECTION TITLE IN ALL CAPS [80 equals signs] N is a positive integer. The title is ALL CAPS. A heading missing either bar is not recognised by the viewer. Section 1 is always titled PURPOSE AND SCOPE. FIRST-WORD RULE: the bottom navigation shows only the first word of each section title, so make the first word a meaningful standalone label (not What, How, The, or A), ten characters or fewer, with no trailing punctuation. SUB-SECTION HEADINGS Format: N.N SUBSECTION TITLE IN ALL CAPS. No bars. One blank line after. Any lowercase letter disqualifies the line from sub-section recognition. BODY TEXT Sentence case, active voice, left-aligned. One blank line between paragraphs. Per R1, each paragraph is a single line; do not wrap it. Indent only inside lists and tables. LISTS Prefix each item with a hyphen and a space. Introduce the list with a colon on the preceding line. Continuation lines for one item indent four or more spaces. Never use the asterisk or the bullet character as a marker; they render literally as text. TABLES Put the column headers on one line in Title Case. The separator line under the headers MUST use the Unicode box-drawing bar U+2500 (─), never the ASCII hyphen, which is not recognised as a column rule. Use at least two spaces between columns. No vertical pipe characters. Null cells use "-" or "N/A". Keep every table line within 80 characters; restructure if it does not fit. ACRONYMS SECTION Title it Acronyms. One entry per line: the code, then two or more spaces, then the definition. Indent each entry two spaces and align the codes in a left column. Example: BPGP Business Plan / General Purpose (Daralbeida plain-text format) SOP Standard Operating Procedure GLOSSARY SECTION Title it Glossary. Use one of two forms per entry. Form A (short): two-space indent, then "Term — Definition", using the Unicode em-dash U+2014 (—) with one space on each side. Form B (long): the Term flush-left on its own line in Title Case, then the definition on the next line indented four spaces and wrapping at the same indent. Separate entries by one blank line. Do not put a header row, lists, tables, or sub-labels inside the glossary. AI PROMPTS SECTION (MANDATORY, R2) Title it AI PROMPTS and place it immediately before the Revision History. Inside, give one copy-paste prompt, wrapped in START and END marker lines, that would regenerate the document at its next version. DOCUMENT CONTROL FOOTER Close the body with an 80-hyphen rule, the line DOCUMENT CONTROL (FOOTER), an 80-hyphen rule, the fields below, and a closing 80-hyphen rule: Document ID : matches the header exactly Version : matches the header exactly Status : ACTIVE Style : BPGP Department : matches the header Last Modified : YYYY-MM-DD HH:MM UTC Review Cycle : 90 days Retention : Duration of Daralbeida operations Owner : PYB / Daralbeida Distribution : Audience descriptor COMPLIANCE : One substantive sentence; never "None" or "N/A" FINAL LINE After one blank line below the footer's closing rule, the absolute final line of the file is exactly: END OF DOCUMENT. No suffix, no Document ID, no punctuation, and no trailing blank line after it. PROHIBITED No Markdown (**, ##, [], and the like). No HTML tags. No bold, italic, or underline. No *** dividers. No asterisk or bullet list markers. No ASCII hyphen as a table column separator. Underscores, not hyphens, in filenames and Document IDs. When ready, ask me for the document's topic, purpose, and audience. Also ask for its department, classification, and the content to include. Then produce the complete, viewer-ready BPGP .txt document. ================================================================================ END — COPY EVERYTHING ABOVE THIS LINE ================================================================================ ================================================================================ 16. REVISION HISTORY ================================================================================ Every revision is logged here, newest row last. Each Summary is terse; fuller detail lives in the body and the relevant section. Version Date Author Summary ─────── ────────── ────── ────────────────────────────────────────────── 1.0 2026-05-01 PYB Initial OPS BPGP standard (DAB-STD-BPGP-001). 1.1 2026-05-25 PYB Editorial clarifications, COMM track. 2.0 2026-05-23 PYB OPS track: replaced file naming convention (entity-first, lowercase ext, no NNN suffix). 2.0 2026-05-29 PYB COMM track: added R1, R2, R3; underscores only in names and IDs. 2.1 2026-05-23 PYB OPS track: compliance corrections; outline expanded; added ASCII, DAB, FFA acronyms. 2.1 2026-05-29 PYB COMM track: full DMS control field set added. 2.2 2026-05-29 PYB COMM track: file names end with YYYYMMDDHHMM (12-digit UTC); added Annual Review field. 3.0 2026-05-30 PYB Consolidation. All four prior BPGP files merged into one comprehensive standard; entity changed to DARH, category to STDS; Document ID DARH_STDS_BPGP_001; viewer parser contracts (Bar-Title-Bar, U+2500 table separator, exact END OF DOCUMENT) integrated as normative rules. 3.1 2026-05-30 PYB Delta issue. Formalised Glossary block (Form A inline em-dash, Form B stacked) and Acronym block (Form A indented, Form B flush-left). Added parser regex contracts. Documented ACRONYM_EXCEPTIONS list for the inline auto-boxer. Originally issued as standalone delta DARH_STDS_BPGP_202605301215.txt. 3.1 2026-06-02 PYB Consolidation issue. v3.0 base and v3.1 delta merged into one standalone v3.1 standard. New sub-sections 9.11, 9.12, 9.13 added under Section 9. Section 10.7 carve-out for U+2014 em-dash as parser contract character. Section 14.5 checklist added. Section 15.7 BPGP generator copy-paste block included so this file is fully standalone. Both prior STDS files superseded by this issue. ================================================================================ 17. ACRONYMS ================================================================================ ACoS Advertising Cost of Sale ADD Business plan additions (category code) AI Artificial Intelligence (chat assistant context) AMZ Amazon and E-Commerce (department and category code) ASCII American Standard Code for Information Interchange BI Business Intelligence (department and category code) BP Business Plan section (type code) BPGP Business Plan / General Purpose (Daralbeida plain-text document standard defined by this file) BRAND Brand and Design (category code) BRIEF Brief (type code; external or contractor brief) COMM Communications and Documentation (department and category code) DAB Daralbeida document and entity prefix (legacy) DARH Daralbeida Holdings LLC (entity code) DARM Daralbeida Maroc SARL (entity code) DARX Daralbeida Brands LLC (entity code; also document-ID prefix) DC Document Control (header and footer blocks) DEPT Department DMS Document Management System EVOO Extra Virgin Olive Oil FFA Free Fatty Acids FIN Finance (department and category code) HTML HyperText Markup Language IOC International Olive Council ISO International Organization for Standardization KB Knowledge Base (category and type code) LAUNCH Launch Planning (category code) LEG Legal and Compliance (department and category code) LOG Log or register (type code) MI Management Information (category code) MKTG Marketing and Brand (department and category code) NNN Three-digit sequential number suffix used in Document IDs OPS Operations and Logistics (department and category code) PROD Product (category code) PYB Founder (internal reference code; see Glossary) QC Quality Control (department and category code) REF Reference document (type code) R1 Rule 1: single-line body paragraphs R2 Rule 2: mandatory AI Prompts section R3 Rule 3: 80-character non-paragraph line limit SOP Standard Operating Procedure (type code) SPEC Specification (type code) STDS Standards (category code; introduced by this document) STRAT Strategy (department and category code) TECH Technology and Systems (department and category code) TOOL Tools and Utilities (category code) TXT Plain text file format extension UTC Coordinated Universal Time UTF-8 Unicode Transformation Format, 8-bit encoding ================================================================================ 18. GLOSSARY ================================================================================ Acronym Block A section of a BPGP document whose section title contains the substring "acronym" (case-insensitive). Its contents are formatted as code-plus-definition rows in Form A (indented) or Form B (flush- left). The viewer renders the section as labelled definition rows. Defined in Section 9.11. ACRONYM_EXCEPTIONS The exception list carried by the viewer's inline acronym auto- boxer. Listed tokens (corporate suffixes such as LLC and SARL, country codes such as US and MA, currency codes such as USD and EUR, and a small set of common doubled-letter words such as OK) are NOT wrapped as inline acronym chips when they appear in body prose. Defined in Section 9.13. Active (Status) Document status indicating the document is the current operative version, has been reviewed and approved, and may be acted upon without further authorisation. At most one file per Document ID is Active at any time. Supersedes any prior version of the same Document ID. Annual Review A mandatory yearly checkpoint date carried by every BPGP document whose Update Cycle is under 365 days. Set to one calendar year after Last Revised. Forces a full review at least once per year independent of the short Update Cycle. When Update Cycle is NONE, no Annual Review date is set. Approved (Status) Document status indicating the document has been signed off but is not yet in force as the operative version for its Document ID. Approved documents become Active when adopted. Bar-Title-Bar Pattern The exact three-line pattern used for top-level section headings: a line of 80 equals signs, then the heading line "N. SECTION TITLE IN ALL CAPS," then a line of 80 equals signs, with no blank lines between the bars and the title. A parser contract. BPGP Business Plan / General Purpose. Daralbeida's plain-text document standard. Governs structure, formatting, required sections, field definitions, file naming, and Document ID conventions. Defined in full by this document, DARH_STDS_BPGP_001. The format is designed for completeness, consistency, precision, and standalone operability without rendering. Earlier OPS-track files used the alternate expansion "Bullet-Proof Ground-Plane"; the current standard uses "Business Plan / General Purpose." Box-Drawing Separator The Unicode character U+2500 (BOX DRAWINGS LIGHT HORIZONTAL), used as the column separator under the header row of every BPGP table. A parser contract: the ASCII hyphen is not recognised in this position and produces a rendering failure. See Section 9.2. Category Code The second token of a file name under the current naming convention. Labels the document and determines which section page lists the file in the viewer's directory via the section map. Must be one of the codes in Section 11.3. Distinct from the Type Code used in Document IDs. Classification A header field indicating the intended audience and distribution restrictions of a document. Standard levels: Internal Confidential, Internal Controlling Reference, Internal Restricted, Internal Contractor Copy. Classification governs distribution; it does not govern document structure. COMPLIANCE Field A mandatory field in the Document Control footer that carries at least one substantive statement of a rule, restriction, or condition a reader acting on the document must not violate. May not read "None" or "N/A." Forces the author to identify and surface the single most operationally critical constraint at the point of distribution. Controlling Reference (Classification) A classification level indicating that a document governs other documents within its scope. A Controlling Reference document takes precedence over general practice and over any document it explicitly supersedes. This standard is Classification Internal, sharable with AI tools and contractors on onboarding; standards that govern other documents may also carry Controlling Reference. Document Control Footer The mandatory closing block of every BPGP document. Carries the recap of header status fields and adds Distribution, Review Triggers, COMPLIANCE, and a Revision History pointer. Triggered by the exact line "DOCUMENT CONTROL (FOOTER)" between two 80- hyphen rules. Document ID A unique identifier assigned to every Daralbeida BPGP document, stable across versions. Format DARX_[DEPT]_[TYPE]_[NNN] with underscores only. The DARX prefix is fixed even for documents whose file name carries DARH or DARM, so the Document ID namespace is shared across entities. Draft (Status) Document status indicating the document is under development or pending review. A Draft document is not operative and should not be acted upon without explicit authorisation from PYB. END OF DOCUMENT Line The mandatory final printable line of every BPGP document. Format: the exact bare string "END OF DOCUMENT," between two lines of 80 hyphens. No suffix, no Document ID, no decorative characters. A parser contract: the viewer's parse loop matches this exact string and terminates. Entity Code The first token of a file name. Identifies the owning legal entity: DARX (Daralbeida Brands LLC), DARH (Daralbeida Holdings LLC), or DARM (Daralbeida Maroc SARL). File Naming Convention The rule set governing how Daralbeida files are named. Current convention: entity-first, date-and-time last, in the form [ENTITY]_[CATEGORY]_[DESCRIPTOR]_[YYYYMMDDHHMM].[ext] with a lowercase extension and underscores only. Defined in Section 11.1. Two legacy conventions are recorded in Section 11.5 as superseded. First-Word Rule The requirement that the first word of every top-level section title be a meaningful standalone label of ten characters or fewer, with no trailing punctuation, suitable for display as a tab in the viewer's bottom navigation bar. Defined in Section 6.4. Glossary The last numbered content section of every BPGP document. Provides full plain-language definitions of every term used in the document that a reader cannot be expected to know without prior training. Distinct from the Acronyms section, which expands abbreviations only. Both sections are mandatory. Hard Wrap Line-length discipline for non-paragraph lines. BPGP enforces 80 characters as the maximum width for every non-paragraph line (R3). Body paragraphs are exempt because under R1 they are single unbroken lines; the reader's editor or the viewer wraps them at display time. In Review (Status) Document status indicating the document has been submitted for review and is awaiting approval. Status value spelled IN_REVIEW in the Status field, with an underscore, for parser consistency. Last Revised The date and 24-hour UTC time of the most recent significant change to the document. Written as YYYY-MM-DD HH:MM UTC. The file name carries the same instant as a 12-digit YYYYMMDDHHMM stamp; the two values must always agree. Outline The second structural element of every BPGP document, appearing immediately after the header control block. Lists every numbered section, sub-section, and sub-sub-section, plus the Document Control footer entry, with correct numbers and titles that exactly match the body. Defined in Section 6. Parser Contract A formatting rule whose purpose is correct viewer rendering. A violation produces a rendering failure, not an aesthetic problem. Examples in this standard: Bar-Title-Bar (Section 7.1), the U+2500 table separator (Section 9.2), the Document Control footer trigger (Section 13.1), and the END OF DOCUMENT line (Section 13.5). PYB Internal reference code for the Daralbeida founder. Used in Document Control fields (Owner: PYB / Daralbeida) and in approval references throughout operational documents. The founder's full name is never written in any Daralbeida document or deliverable. Retired (Status) Document status indicating the document has been withdrawn from use and is retained for historical reference only. A retired document must not be acted upon and has no successor. Revision History A section near the end of every BPGP document, immediately after AI Prompts and before Acronyms, recording the audit trail of the document. One row per version, newest row last. Defined in Section 16 (this document) and described in Section 7.4. Section Map The PHP file darx_section_map.php at the project root that maps each Category Code to a section page in the viewer's directory. The source of truth for dynamic directory placement (Section 11.4). Changing a category-to-section mapping in this file moves every file in that category to a new section without renaming. Series of Codes The full set of three code families that a BPGP file name and Document ID use: Entity Codes (Section 11.2), Category Codes (Section 11.3), and Type Codes (Section 11.8). The Department Codes (Section 11.7) are used in Document IDs and in the Department header field. Status A header and footer field indicating the lifecycle state of a document. Six allowed values: DRAFT, IN_REVIEW, APPROVED, ACTIVE, SUPERSEDED, RETIRED. Each is defined individually in this Glossary. Status must be identical in both the header and the footer block. Sub-Label Block A line that begins with an uppercase letter, ends with a colon, contains no other content, and is fewer than fifty characters long. The viewer renders it as a styled uppercase label above the following content. Defined in Section 9.8. Superseded (Status) Document status indicating the document has been replaced by a newer version named in the Superseded By field. The superseded document is retained for reference but is no longer operative. Template Block A block introduced by a line of the form "Template, [topic]" (the literal word Template, a comma, then the topic). The viewer renders it as a styled quotation with a gold left border. Use for sample subjects, sample messages, and small literal content the reader is expected to copy. Defined in Section 9.9. Type Code The third token of a Document ID. Identifies the type of document: BP, BPGP, BRIEF, KB, LOG, REF, SOP, or SPEC. Defined in Section 11.8. Distinct from the Category Code used in file names. Update Cycle The maximum interval, in days, between scheduled reviews. One of 30, 60, 90, or NONE. Operational documents typically carry 30 or 60; standards typically carry 90; settled reference documents carry NONE. Drives the Next Review Due derivation. Em-Dash The Unicode character U+2014. Distinct from the ASCII double-hyphen and the en-dash U+2013. BPGP Glossary Form A requires U+2014 specifically; entries using any other dash will not be detected by the parser and will render as plain paragraph text. The em-dash is a parser contract character within Glossary blocks; its use anywhere else in body text remains prohibited as decorative. See Section 9.12 and Section 10.7. Form A (Acronym Block) The indented code-plus-definition layout for acronym entries. Each line begins with two or more spaces, then a code of one to twelve characters, then two or more spaces, then the definition. The historically preferred form, used throughout v3.0-era documents. Defined in Section 9.11. Form A (Glossary Block) The inline em-dash layout for glossary entries. Each entry is one line of the form "Term — Definition", indented two spaces, with the term and definition separated by U+2014 em-dash surrounded by one space on each side. Preferred when definitions fit on roughly 200 to 280 characters. Defined in Section 9.12. Form B (Acronym Block) The flush-left code-plus-definition layout for acronym entries. Each line begins at column zero with an uppercase code of one to twelve characters, then two or more spaces, then the definition. Accepted as of v3.1, used in shorter documents. Defined in Section 9.11. Form B (Glossary Block) The stacked layout for glossary entries. The term appears flush- left on its own line in Title Case; the definition follows on the next line indented by four spaces and may wrap over several indented lines. Preferred when definitions run paragraph-length. Defined in Section 9.12. Glossary Block A section of a BPGP document whose section title contains the substring "glossar" (case-insensitive). Its contents are formatted as term-and-definition entries in Form A (inline em-dash), Form B (stacked), or a mix of both. The viewer renders the section as labelled definition rows. Defined in Section 9.12. Inline Acronym Auto-Boxer A viewer feature that scans body text for runs of two or more uppercase letters and wraps each as a styled acronym chip when at least one neighbour word contains a lowercase letter. The ACRONYM_EXCEPTIONS list prevents corporate suffixes, country codes, currency codes, and similar tokens from being chip-wrapped. Defined in Section 9.13. Parser Contract A formatting rule whose precise textual pattern is required for the viewer's parser to detect and structure the content correctly. A document that deviates from a parser contract will render the affected element as plain paragraph text instead of as the intended block type. The parser contracts in v3.1 are: the Bar- Title-Bar section heading pattern (Section 7.1), the U+2500 table column separator (Section 9.2), the Acronym block regexes (Section 9.11), the Glossary block regex and stacked-detection algorithm (Section 9.12), and the exact END OF DOCUMENT terminator line (Section 13.5). -------------------------------------------------------------------------------- DOCUMENT CONTROL (FOOTER) -------------------------------------------------------------------------------- Document ID : DARH_STDS_BPGP_001 Version : 3.1 Status : DRAFT Last Modified : 2026-06-02 00:36 UTC Update Cycle : 90 days Next Review Due : 2026-08-31 Annual Review : 2027-06-02 Owner : PYB / Daralbeida Distribution : Internal; all principals, contractors, and AI systems producing or reviewing Daralbeida BPGP documents. Issued on onboarding. Section 15.6 regeneration prompt may be shared into AI chats as needed. Review Triggers : Any structural change to Daralbeida document practice; any new entity, department, category, or type code; any change to the parser contracts of the live viewer; any identification of a BPGP compliance failure in a published document; annual review on the Annual Review date above. COMPLIANCE : All plain-text Daralbeida documents must conform to this standard before being marked ACTIVE. A document missing any mandatory section (AI Prompts, Revision History, Acronyms, Glossary, Document Control footer, END OF DOCUMENT line) or violating R1, R2, or R3 is non- compliant and must not be distributed or acted upon. Non-compliance identified post-distribution must be corrected and re-issued with a version increment and a Revision History entry. The Section 15.6 regeneration prompt must be kept in sync with this document on every revision. Revision History: See Section 16 -------------------------------------------------------------------------------- END OF DOCUMENT