3. Profile Metadata & Formatting Rules

Every CAR Profile is a human-readable, text-based document formatted using standard Markdown (.md). This allows portability, offline editing, AI compatibility, and zero reliance on proprietary tools or templates.

Index:
3. Profile Metadata & Formatting Rules
3.1 Metadata Block
3.2 Manual vs. AI-Generated Profiles
3.3 SLOT System Overview
3.4 Trust Layers & Verification Tags
3.5 Revisioning & Version Control
3.6 Profile Sharing & Repository Standards

📎 Metadata Block (Required)

Each CAR Profile must begin with a YAML-style metadata header or an equivalent Markdown block including:

CARS Profile Specification Version: 1.0
Date Created: {yyyy-mm-dd}
Last Reviewed: {yyyy-mm-dd}
Profile Version: {e.g., 1.3.2 or “Draft”}
Status: Planning / Draft / Testing / Active / Deprecated
Maintainer: {Driver Name, Alias, or Group}

3.2 Manual vs. AI-Generated Profiles

The CARS system is designed to support two equally valid creation methods:

  • Manual Profile Creation — by human users using the CARS Workbook, pen and paper, or any Markdown editor
  • AI-Assisted Profile Generation — using approved Digital Freedom Alliance tools, SLOT generators, or virtual assistants

✍️ Manual Profile Creation

CARS Profiles can be built entirely without automation or AI. This ensures:

  • Full transparency and auditability
  • Maximum privacy (no external inference)
  • Use in high-risk or offline environments

Manual profiles must:

  • Follow the formatting rules in Section 3.1
  • Complete all Required Subheadings
  • Mark unused SLOTs as “Not Used” or remove them
  • Use {} brackets to denote empty or partially populated fields

🤖 AI-Generated Profiles

AI assistants can help users build CARs by:

  • Populating SLOT modules (prebuilt sub-profiles)
  • Importing reusable templates from the user’s Workbook
  • Checking internal consistency (Driver/Destination match)
  • Calculating trust scores, revision metadata, and output hashes

AI-generated profiles:

  • Must still follow all formatting rules
  • Are required to insert a trust verification label:
    "Generated by DFA-verified AI — Untouched" or "Post-edited by User"
  • Must never insert real personal data unless explicitly instructed
  • Must identify inserted SLOTs using structured headers

🛡️ Hybrid Profiles

Many profiles will be created in hybrid mode:

  • User creates core content manually
  • AI fills in SLOTs or runs final verification
  • Some fields may be marked as {Requires Review} before release

This hybrid model supports:

  • Privacy-preserving drafts
  • AI acceleration without AI overreach
  • Human ownership with optional machine support

AI assistance should never replace user intent. The goal of automation is clarity, not control.

3.3 SLOT System Overview

SLOTs are modular, swappable sub-profiles that reduce duplication, speed up profile creation, and support automation. Each SLOT represents a predefined set of fields that replaces one or more Level 2 groups within a CARS Profile.

They are the foundation of profile reuse, AI-assisted building, and trust-verifiable components.

🔖 What is a SLOT?

A SLOT is a “reserved subheading” in the CARS Profile format.
SLOTs appear at Level 2 as:

Virtual Driver’s License SLOT (Section 2 Identity group)

When this SLOT is inserted, it replaces:

  • The corresponding Required group
  • Sometimes the Recommended group, depending on SLOT type

🧩 Types of SLOTs

  • Identity SLOTs
    Replace Driver group(s), e.g., Virtual Driver’s License, Risk Profile
  • Destination SLOTs
    e.g., Digital Life Navigation Map
  • Technology SLOTs
    e.g., Tech Stack Pit Crew
  • Privacy SLOTs
    e.g., Tinted Windows
  • Security SLOTs
    e.g., Armor Plating Kit
  • Operational SLOTs
    e.g., Mechanic’s Manual, Aftermarket Mods
  • Lifecycle SLOTs
    e.g., Crash Test Report, Service Log

Every section has at least one SLOT defined or reserved.

📥 SLOT Structure & Formatting

  • Declared using a Level 2 Reserved Header
  • Always include the name of the group it replaces
  • Must not be renamed or repurposed
  • Can include an inline reference to its source:
    {Imported from: SLOT_Library/Driver_Alias_X}

✅ SLOT Behavior Rules

  • If a SLOT is used, its matching Required Subheadings are not required
  • SLOTs must either:
    • Fully replace a group, or
    • Explicitly indicate which fields are excluded
  • SLOT content may be hidden, summarized, or embedded — depending on context

🧠 SLOT Generation

SLOTs can be:

  • Manually created and stored in the user’s Workbook
  • Auto-generated by trusted AI Assistants
  • Pulled from a DFA-approved repository
  • Reused across CARs with shared characteristics

SLOTs allow CARS to scale. They turn profile building into modular assembly — but without compromising transparency or user control.

3.4 Trust Layers & Verification Tags

CARS Profiles are intended to be modular, portable, and shareable — but trust must be explicitly declared and verifiable. The system includes a set of optional but strongly encouraged mechanisms to support chain-of-trust, validation, and auditability.

🔐 Purpose of Trust Metadata

Trust metadata helps users determine:

  • If the CAR has been altered
  • If it was generated or reviewed by a known, trusted AI assistant
  • If SLOTs or sub-profiles come from a verified source
  • Whether the profile is current and actively maintained

This increases confidence, especially when CARs are reused, shared, or loaded from public repositories.

✅ Trust Tags

CAR Profiles may include one or more of the following verification tags at the top or near the metadata block:

  • "Verified + Untouched"
    Generated by a DFA-certified AI and not manually altered after creation
  • "Post-edited by User"
    AI-generated, but user has manually reviewed and edited the profile
  • "Checksum Validated"
    File hash has been confirmed against repository copy or original output
  • "Legacy Manual Draft"
    Profile was built manually before automation tools or without AI assistance

🧾 Checksum Validation

Each CAR Profile may include a comment block containing a cryptographic hash of its contents:

SHA256:a3d4c8120b3e91eaa58a2f4a…

This can be used to:

  • Detect tampering
  • Confirm file integrity
  • Enable fast trust verification across systems

Hashes may be auto-generated by trusted tools at the time of CAR creation or repository upload.

📷 QR Code Loading

To improve accessibility and use on mobile or air-gapped devices:

  • CARs may include a QR code link to their .md file
  • QR codes may encode either:
    • A public URL to a read-only copy
    • A local or LAN-based import location

🧠 AI-Verified Metadata and Trust Labels

When AI tools generate or validate a CAR:

  • They must insert a trust label block
  • Optionally, they may sign the file with a structured metadata object (e.g., JSON-LD block or YAML front-matter)
  • Profiles downloaded from the DFA repository will include a structured trust stamp, version history, and optionally, a CAR Trust Score

Trust must be transparent. AI isn’t just a builder — it’s part of the audit trail. This section provides the foundation for shared CARS to be useful and safe.

3.5 Revisioning & Version Control

Every CAR Profile is a living document. Over time, technologies evolve, threats change, tools are updated, and user needs shift. To support this lifecycle, CARS includes a clear system of profile versioning and revision tracking.

This ensures profiles are:

  • Maintainable over time
  • Transparent in their history
  • Traceable when reused or shared
  • Trustworthy when downloaded from a repository

Profile Version Format

Version numbers follow a semantic-style pattern:

Major.Minor.Revision

  • Major = Structural changes (e.g. new sections, format overhaul)
  • Minor = New content, SLOT updates, added capabilities
  • Revision = Minor edits, typo fixes, clarity updates

Examples:

  • 1.0.0 — Initial complete release
  • 1.1.0 — New SLOTs added, extra fields included
  • 1.1.3 — Minor fixes and field clarifications

Revision Metadata

Each CAR Profile must include the following metadata near the top:

Date Created: yyyy-mm-dd
Last Reviewed: yyyy-mm-dd
Profile Version: x.y.z
Maintainer: {Driver, Team, Alias, or Role}

These fields help track:

  • How recent the profile is
  • When it was last validated
  • Who’s responsible for updates

Backup & History Practices

Profiles may include or be stored with:

  • Changelog notes (either embedded or stored in a sidebar log)
  • Previous versions with version ID and timestamp
  • Exportable diffs for collaboration or audit trail

In organizational or team use, all changes should be reviewed and approved by a designated Maintainer Role.

AI-Generated Revisions

When a trusted AI Assistant generates or updates a profile, it must:

  • Insert a timestamp of when the revision occurred
  • Mark whether the profile was:
    • "Generated by DFA AI"
    • "Post-edited by User"
  • Log which SLOTs or sections were inserted or changed

Repository Best Practices

In shared or official use, every CAR Profile in a repository:

  • Should include a version label
  • May include a checksum
  • Must include a trust label if AI-generated
  • Should preserve prior revisions unless explicitly deprecated

Digital freedom isn’t a one-time fix — it’s a practice. Versioning gives you the tools to evolve, improve, and maintain trust over time.

3.6 Profile Sharing & Repository Standards

CARS Profiles are designed to be private by default but portable by design. While many users will create and maintain their profiles locally, the system also supports optional sharing through trusted repositories.

Shared profiles help grow the CARS ecosystem by allowing Trailblazers to publish templates, SLOTs, and reference builds for others to adapt and learn from.

📤 Sharing a CARS Profile

To be shared safely and effectively, a CARS Profile must:

  • Follow the official Markdown (.md) structure defined in Section 3
  • Include accurate metadata (version, author, date, status)
  • Remove or isolate all personal information
    • Move sensitive notes under the ## Personal Information (Global Subheading)
    • Omit this section when publishing
  • Include at least one of the following Trust Tags:
    • "Generated by DFA AI — Untouched"
    • "Post-edited by User"
    • "Legacy Manual Draft"
    • "Checksum Validated"

🗃️ Official Repository Standards

Profiles published to the Digital Freedom Alliance Repository must:

  • Pass structural validation
  • Include version and revision history
  • Contain no real personal or identifying information
  • Be tagged using appropriate keywords (e.g. Purpose, Platform, Tools)
  • Be compatible with the current CARS Profile Specification version

Each submitted profile will be reviewed and may receive:

  • ✅ Verification Label — AI or human-reviewed
  • 🔒 Lock Notice — profile is deprecated or read-only
  • 🛠️ SLOT Compatibility Warning — if SLOTs used are legacy or untrusted

🧩 SLOT Submission & Reuse

Users may contribute new SLOTs to the repository if they:

  • Match an existing reserved SLOT type or propose a new one
  • Are documented using the official SLOT Template
  • Do not conflict with reserved naming
  • Include structured metadata:
    • SLOT Name
    • Purpose
    • Source / Author
    • Compatibility range
    • Trust label
    • Version

Trusted SLOTs can then be used in any CAR Profile via their reserved heading and import path.

🔁 Downloading from the Repository

When downloading a CAR Profile from the DFA Repository:

  • Users can view a Trust Score, ratings, and version history
  • Each file includes:
    • Trust tag
    • Optional QR code
    • SHA-256 checksum for verification
    • Compatible SLOT references

Profiles downloaded in this way are always generic — no personal data is included.

🔒 Local Validation Tools

To support safe reuse and verification, CARS tools may include:

  • A local or browser-based Checksum Validator
  • QR Code Scanners to import profiles into your vault
  • AI Snapshot Reviewers that confirm structural integrity and SLOT authenticity

These tools will be included in the open-source CARS Toolkit and may be embedded into the Workbook or companion web platform.

Sharing CARs helps others escape. But the price of sharing is trust. Repository rules ensure profiles are verifiable, usable, and never compromise your privacy.