Profiles are documentation overlays that describe how to use PEAC for specific use cases, regulatory contexts, or integration patterns. A profile does NOT add new schema fields: it constrains and documents existing PEAC structures.
Profiles are documentary, not runtime-enforced. Schema validation (@peac/schema)
enforces field structure; verifyLocal() enforces protocol behavior including
type-to-extension enforcement. Profiles document recommended usage patterns on
top of those layers.
Profiles constrain existing schema fields; they never add new wire format fields.
See docs/specs/WIRE-0.2.md section 12 for the normative extension group specification.
Pillar profiles document how to use a specific PEAC extension group for a regulatory, operational, or evidence workflow.
| Profile | Extension Group | Since | Status |
|---|---|---|---|
| Access | org.peacprotocol/access |
v0.12.2 | Draft |
| Identity | org.peacprotocol/identity |
v0.12.2 | Draft |
| Consent | org.peacprotocol/consent |
v0.12.2 | Draft |
| Privacy | org.peacprotocol/privacy |
v0.12.2 | Draft |
| Safety | org.peacprotocol/safety |
v0.12.2 | Draft |
| Compliance | org.peacprotocol/compliance |
v0.12.2 | Draft |
| Provenance | org.peacprotocol/provenance |
v0.12.2 | Draft |
| Attribution | org.peacprotocol/attribution |
v0.12.2 | Draft |
| Purpose | org.peacprotocol/purpose |
v0.12.2 | Draft |
| Commerce | org.peacprotocol/commerce |
v0.12.4 | Draft |
Adapter profiles document how to normalize external protocol artifacts into PEAC receipts for a specific integration.
| Profile | Package | Since | Status |
|---|---|---|---|
| Stripe x402 Machine Payments | @peac/rails-stripe |
v0.10.11 | Draft |
| Runtime Governance | @peac/adapter-runtime-governance |
v0.12.10 | Draft |
| ACP Delegated Payment | @peac/mappings-acp |
v0.12.11 | Draft |
| MPP Payment Evidence | @peac/mappings-paymentauth |
v0.12.11 | Draft |
PEAC uses two profile templates. Choose the one that matches your use case.
For profiles that document how to use a PEAC extension group for a specific evidence or regulatory workflow. No backing package required.
- Abstract: one-paragraph description of the profile and its purpose
- When to use: scenarios where this profile applies
- Required / Recommended / Prohibited fields: which fields from the extension group are REQUIRED, RECOMMENDED, or PROHIBITED for this profile, using RFC 2119 keywords
- Minimal valid receipt: the smallest receipt that satisfies this profile
- Companion profiles: recommended combinations with other profiles
- Regulatory context: specific regulations or standards this profile supports evidence for, using neutral wording ("supports evidence relevant to", "can help document"; never "required for compliance")
- Conformance examples: documentary examples in a standardized pattern:
- Minimal valid issue example
- Verify example
- Invalid example (violates a profile constraint, with explanation)
- Companion-profile example where relevant (two profiles combined)
- Quick demo: a runnable TypeScript snippet (issue + verify) a stranger can execute in under 5 minutes
- Non-goals / not guaranteed: must state plainly that the profile:
- does not create new schema fields
- does not by itself establish legal compliance
- does not imply verifier enforcement beyond what the protocol spec defines
- Notes / caveats: limitations, future directions, or scope boundaries
For profiles that document how to normalize external protocol data into PEAC receipts for a specific integration. Requires a backing package.
- Abstract: one-paragraph description
- Use case: the scenario this profile targets
- Package / Function: the backing
@peac/rails-*or@peac/adapter-*package - Mapping: input/output field mapping tables
- Validation rules: numbered, testable invariants
- Conformance vectors: link to fixtures in
specs/conformance/fixtures/under the relevant category - Quick demo: a runnable command a stranger can execute in under 5 minutes
- Example: inline code showing the happy path
Profile documents that reference regulations or standards must use neutral, evidence-oriented language:
- "supports evidence relevant to [Article X] workflows"
- "can help document [requirement Y]"
- "maps naturally to [standard Z] concepts"
Do NOT use language that implies direct compliance or legal sufficiency:
"required for [Article X] compliance""ensures GDPR conformance""satisfies [regulation] requirements"
PEAC is evidence and interoperability infrastructure. Extension groups and profiles support workflows relevant to regulatory requirements; they do not themselves constitute compliance artifacts.
Certain profiles are natural companions for common regulatory workflows:
| Workflow | Recommended Profiles | Context |
|---|---|---|
| GDPR evidence | Consent + Purpose | Art 6-7 legal basis + Art 5(1)(b) purpose limitation |
| GDPR data handling | Privacy + Consent | Art 13-14 disclosure + Art 7 consent |
| EU AI Act risk management | Safety + Compliance | Art 9 risk management + Art 28 deployer obligations |
| AI-generated content | Provenance + Attribution | Art 50 transparency + content origin |
| SOC 2 / ISO 27001 audit | Compliance | Standalone; audit reference + framework |
| Content licensing | Attribution + Provenance | SPDX license + origin tracking |
Profiles live in docs/profiles/ and are linked from this index.