Standards should not be authored as prose. They should be compiled from a typed model.

Today's standards leave agents doing extraction work.

HTML prose
  → find normative sentence
    → infer target
      → infer condition
        → infer testability
          → map to examples
            → map to behavior

AFSL source
  → generated W3C-style HTML
  → generated normative-requirement index
  → generated JSON Schemas
  → generated SHACL shapes
  → generated conformance test manifest
  → generated implementation report template
  → generated llms.txt / agent manifest

Specifications like the W3C Verifiable Credentials Data Model 2.0 embed normative meaning in prose. JSON-LD contexts, examples, and test suites help, but agents still reconstruct intent from paragraphs. AFSL inverts the pipeline: a single structured source generates the human document, schemas, tests, and agent manifests.

Five layers, separated by purpose.

A normative sentence becomes a typed object.

id: VC-DM-4.3-R002
section: "4.3"
title: The base VC context is first

normative:
  modality: MUST
  original_text: >
    The value of the @context property MUST be an ordered set
    where the first item is the URL
    https://www.w3.org/ns/credentials/v2.

subjects: [VerifiableCredential, VerifiablePresentation]
conformance_targets:
  - conforming_document
  - conforming_issuer
  - conforming_verifier

formalization:
  language: afsl-expr
  expression: >
    first(normalize_context(document["@context"])) ==
    "https://www.w3.org/ns/credentials/v2"

checkability:
  level: machine_checkable

test_vectors:
  positive: [tests/context-array-base-first.valid.json]
  negative:
    - tests/context-array-base-second.invalid.json
    - tests/context-missing.invalid.json

failure:
  expected_error:
    code: VC_CONTEXT_INVALID
    severity: error
    retryable: false

traceability:
  source_spec: vc-data-model-2.0
  source_url: "https://www.w3.org/TR/vc-data-model-2.0/#contexts"

Edit a requirement. Watch prose, schema, and tests regenerate.

The same source object compiles to three artifacts on every keystroke: a paragraph for human review, a JSON Schema fragment for document validation, and a conformance test manifest for implementation runs. Edit the YAML on the left to see the outputs stay in lockstep on the right.

§ 4.3 — The base VC context is first

This is a normative requirement (VC-DM-4.3-R002). It applies to VerifiableCredential, VerifiablePresentation and is binding on conforming_document, conforming_issuer, conforming_verifier.

The value of the @context property MUST be an ordered set where the first item is the URL https://www.w3.org/ns/credentials/v2.

Checkability is declared as machine_checkable. A formal expression is provided in afsl-expr for automated evaluation. Failures MUST be reported with error code VC_CONTEXT_INVALID.

Source: https://www.w3.org/TR/vc-data-model-2.0/#contexts

This compiler runs entirely in your browser. It is intentionally minimal — a real AFSL toolchain emits SHACL, OpenAPI, ReSpec, agent manifests, and more from the same source.

Every requirement, mapped to its targets and checkability.

A conformance matrix is the agent-friendly form of a standard's obligations. It answers, in one view: which requirements apply to which conformance targets, how each can be evaluated, and how much of the standard is mechanically verifiable. Filter by modality, checkability, or target.

Make ambiguity explicit, typed, and bounded.

Not every standards statement can or should be fully formalized. AFSL classifies every requirement by checkability so that ambiguity is declared rather than hidden. The goal is not zero ambiguity — it is no hidden ambiguity.

Six levels — and exactly what each one generates.

@context[0] == "https://www.w3.org/ns/credentials/v2"

Issuer MUST reject a credential with expired status list.

Verifier MUST refresh status list at most every 15 minutes.

Privacy considerations MUST be documented per § 8.2.

Issuers SHOULD use cryptographically agile signature suites.

"Note: implementations may cache the context document."

Profiles (§ 11) can refine a requirement to a stricter level — typically policy_judgment → machine_checkable — but they can never relax one. This monotonicity is what lets a deployment trust that "AFSC: pass" means the same thing across ecosystems.

Documents, issuers, verifiers — first-class objects.

Every requirement attaches to one or more targets, so a verifier test suite knows precisely which obligations apply — and which to skip.

AFSL orchestrates the standards you already use.

Conformance tests for standards themselves.

Agent-First Standards Conformance (AFSC) defines tests that a standards document itself must pass to claim agent-first status. A standards body can publish a machine-readable conformance score for the standard, the same way AFPS scores a project.

Download a runnable AFSL example bundle.

afsl-example-bundle/
├── README.md
├── manifest.json
├── sources/
│   ├── vocabulary.afsl.yaml
│   ├── shapes.afsl.yaml
│   ├── requirements.afsl.yaml
│   ├── algorithms.afsl.yaml
│   └── tests.afsl.yaml
├── schemas/
│   └── verifiable-credential.schema.json
├── shapes/
│   └── verifiable-credential.shacl.ttl
├── profiles/
│   └── mdl.profile.afsl.yaml
├── tests/
│   ├── conformance-manifest.json
│   └── vectors/
│       ├── context-array-base-first.valid.json
│       ├── context-array-base-second.invalid.json
│       ├── context-missing.invalid.json
│       └── validity-period-mdl.valid.json
└── generated/
    ├── requirement-index.json
    ├── llms.txt
    └── implementation-report.template.json

Domain profiles refine ambiguous requirements.

A profile is a downstream document that extends a base standard for a specific domain. Profiles are first-class AFSL artifacts: they reference base requirements by ID and apply one of four operations — refine, tighten, override, or forbid — to turn ambiguous obligations into checkable ones.

requirement:
  id: VC-DM-5.4-R001
  section: "5.4"
  title: Validity periods should be appropriate
  normative:
    modality: SHOULD
    original_text: >
      Validity periods should be appropriate
      to the use case of the verifiable credential.
  subjects: [VerifiableCredential]
  conformance_targets: [conforming_issuer]
  checkability:
    level: policy_judgment
  refinement_hint: >
    Refine in a domain profile to a checkable
    duration constraint.

profile:
  id: mobile-driving-license-profile
  title: Mobile Driving License (mDL) Profile
  version: 1.0.0
  extends: vc-data-model-2.0
  jurisdiction: ISO/IEC 18013-5
  status: draft

requirements:
  # 1. REFINE — turn policy_judgment into a checkable rule
  - id: MDL-VALIDITY-R001
    refines: VC-DM-5.4-R001
    operation: refine
    modality: MUST
    title: mDL validity period MUST NOT exceed 8 years
    formalization:
      language: afsl-expr
      expression: >
        duration(validFrom, validUntil) <= P8Y
    checkability: { level: machine_checkable }
    failure:
      expected_error:
        code: MDL_VALIDITY_TOO_LONG
        severity: error
        retryable: false
    test_vectors:
      positive: [tests/mdl/validity-8y.valid.json]
      negative: [tests/mdl/validity-10y.invalid.json]

  # 2. TIGHTEN — narrow an already-checkable rule
  - id: MDL-ISSUER-R001
    tightens: VC-DM-5.5-R001
    operation: tighten
    modality: MUST
    title: mDL issuer MUST be a registered issuing authority
    formalization:
      language: afsl-expr
      expression: >
        is_uri(issuer_id(document.issuer)) AND
        issuer_id(document.issuer) IN registry("iaca")
    checkability: { level: machine_checkable }

  # 3. OVERRIDE — replace base behavior entirely
  - id: MDL-CONTEXT-R001
    overrides: VC-DM-4.3-R002
    operation: override
    rationale: >
      mDL uses a domain-specific context bundle. The base context
      MUST appear second, after the mDL context.
    modality: MUST
    formalization:
      language: afsl-expr
      expression: >
        context[0] == "https://iso.org/mdl/v1" AND
        context[1] == "https://www.w3.org/ns/credentials/v2"
    checkability: { level: machine_checkable }

  # 4. FORBID — disallow a permitted option
  - id: MDL-NO-BBS-R001
    forbids: VC-DM-PROOF-BBS
    operation: forbid
    modality: MUST_NOT
    rationale: >
      BBS+ proofs are not certified for mDL deployments
      under ISO/IEC 18013-5.
    checkability: { level: machine_checkable }

AFSL · AFSC · AFPS — three layers, one ecosystem.

The same triad runs top-to-bottom: a standard is authored in AFSL, audited by AFSC, and applied to implementations by AFPS. Each layer takes the previous layer's output as its input and emits its own generated artifacts.