Document Purpose: Architecture for the protocol-level parameterization layer that adapts AURA’s invariant protocol mechanics to different market contexts (retail, B2B, services, digital goods) without forking the specification. Owner: Marc Massar, AURA Labs Version: 1.1 Last Updated: April 14, 2026 Protocol: v2.2 Status: Architecture Designed (DEC-044) Authority: DEC-044 (Market Profiles) References: MARKET_ECONOMICS.md (Sections 10, 11), PROTOCOL_SPECIFICATION.md v2.2, CLEARINGHOUSE.md (Section 11), NEUTRAL_BROKER.md
The AURA protocol defines message formats, state machines, cryptographic integrity, and clearing mechanics that work across any agent-mediated commerce scenario. But the economic parameters that govern participation, disclosure, commitment, and risk vary fundamentally across market contexts.
A retail consumer browsing headphones and a procurement agent sourcing industrial components use the same protocol. They should not face the same participation costs, disclosure rules, commitment thresholds, or risk margins. The protocol must be invariant. The economic rules must be variant.
Without a formal parameterization layer, three failure modes emerge:
A Market Profile is a protocol-level configuration object that parameterizes six dimensions of market behaviour:
| Dimension | What it governs |
|---|---|
| Participation | Cost of entry, rate limits, bonding, quality-weighted access |
| Disclosure | What information is visible at each protocol phase |
| Commitment | Required commitment states, binding thresholds, withdrawal rules |
| Risk | Risk weights, margin floors, decay rates, enforcement thresholds |
| Schema | Domain-specific attribute overlays on canonical core fields |
| Identity | Trust Framework reference, minimum trust levels per action, credential preferences |
The protocol defines the mechanics (where costs are evaluated, how disclosure progresses, what commitment states exist). The profile sets the values (what the costs are, what’s visible when, which states are required).
This architecture is driven by three converging signals:
The protocol specification (message formats, state machine transitions, cryptographic integrity, clearing lifecycle) does not change between profiles. A session created under a B2B profile uses the same state machine as a retail session. The transitions are identical. The conditions under which transitions occur are parameterized.
Every profile parameter is inspectable by all participants before they enter a session. An agent can query a Core instance’s active profile and decide whether to participate. This is equivalent to reading a venue’s trading rules before placing orders on an exchange.
If a rule affects agent behaviour or economic outcomes, it must be a named parameter in the profile. Informal conventions, undocumented defaults, or implementation-specific behaviours that affect outcomes violate profile transparency. If it matters, it’s in the profile.
Within any profile, information disclosure can only increase as commitment increases. No protocol phase reveals less than the previous phase. This is a structural guarantee, not a policy choice. It prevents implementations from regressing disclosure during negotiation — a technique that could be used to manipulate counterparties.
Profiles are not monolithic. Each dimension (participation, disclosure, commitment, risk, schema) can be specified independently. A deployment can compose a profile by selecting a participation policy, a disclosure policy, a commitment model, a risk configuration, and a schema overlay. This allows mix-and-match without combinatorial explosion.
A deployment that does not declare a profile operates under the default profile, which reproduces the current protocol behaviour (v2.0). No existing implementation breaks. The default profile is not a special case — it is a concrete profile with specific parameter values.
Participation economics govern the cost of entering and operating within the market. The protocol defines where costs are evaluated (session creation, offer submission, commitment, dispute filing). The profile sets what those costs are.
The protocol defines six evaluation points where participation costs can be assessed:
| Evaluation Point | Who pays | Protocol phase | Example |
|---|---|---|---|
| Session creation | Scout | Session initiation (Section 5) | Rate limit, compute credit, zero (retail) |
| Offer submission | Beacon | Offer response (Section 8) | Per-offer fee, quality bond, zero (open marketplace) |
| Commitment | Scout | Transaction commitment (Section 10) | Transaction fee, staking deposit |
| Clearing | Both | Clearinghouse flow (Section 10.7) | Risk margin (already defined), clearing fee |
| Dispute filing | Filer | Dispute initiation (Section 11) | Filing bond (refundable if upheld), zero (consumer protection) |
| Beacon qualification | Beacon | Registration / renewal (Section 7) | Annual listing fee, reputation bond, zero (open marketplace) |
Each evaluation point accepts one or more cost types:
| Cost Type | Mechanic | Example Use |
|---|---|---|
zero |
No cost. Default for Scout session creation in retail profiles. | Consumer browsing |
rate_limit |
Maximum actions per time window. No monetary cost. | Anti-probing for open marketplaces |
compute_credit |
Deducted from a pre-purchased credit balance. | B2B platforms with subscription models |
per_action_fee |
Fixed fee per action (session, offer, commit). | High-volume B2B with fee-based access |
quality_bond |
Refundable deposit returned if action meets quality criteria. | Beacon offer quality enforcement |
staking_deposit |
Locked deposit released after dispute window. | High-value transactions |
percentage_fee |
Percentage of transaction value. | Marketplace commission model |
participation:
scout:
session_creation:
cost_type: "zero" # Retail: free browsing
rate_limit:
max_sessions_per_hour: 20 # Anti-probing
max_sessions_per_day: 100
commitment:
cost_type: "percentage_fee"
percentage: 0.0 # No buyer fee in retail
dispute_filing:
cost_type: "zero" # Consumer protection default
beacon:
qualification:
cost_type: "quality_bond"
bond_amount: 500.00 # USD equivalent
bond_currency: "USD"
bond_return_conditions:
min_fulfillment_rate: 0.95
min_sessions_for_evaluation: 50
offer_submission:
cost_type: "rate_limit"
max_offers_per_session: 5 # Already in spec (configurable)
max_offers_per_hour: 200
clearing:
cost_type: "percentage_fee"
percentage: 0.025 # 2.5% clearing fee
Cost structures must satisfy three properties from MARKET_ECONOMICS.md:
Information staging governs what each party can see at each phase of the protocol. The protocol defines the phases and the disclosure mechanics (field-level visibility, redaction, projection). The profile sets the disclosure schedule — what’s visible when.
The protocol has five natural disclosure phases, aligned to the session state machine:
| Phase | State | Scout sees | Beacon sees | Core holds |
|---|---|---|---|---|
| P1: Session | created → interpreting |
Own intent, constraints | Nothing (not yet matched) | Full intent + constraints |
| P2: Discovery | interpreting → matching |
Status | Interpreted request (projected) | Full interpretation |
| P3: Offers | offers_available |
Ranked offers, Beacon attributes (projected) | Own offer status, aggregate demand signals | All offers, all Beacon attributes |
| P4: Commitment | committed → risk_assessed |
Selected offer + payment terms, Beacon identity | Scout identity (revealed), payment confirmation | Full bilateral identity |
| P5: Settlement | authorized → cleared |
Transaction status, clearing status | Settlement status, payout timeline | Full clearing record |
Key insight: The transition from P2 to P3 is where the profile has the most impact. What Beacons see in the interpreted request — and what Scouts see in offer attributes — is the primary lever for information staging.
Each field in the interpreted request and offer response can be assigned a disclosure tier:
| Tier | Meaning | Example |
|---|---|---|
full |
Field is visible in its entirety | Product category, hard constraints |
range |
Field is visible as a range, not an exact value | Budget shown as “$200–$500” instead of “$347” |
presence |
Field existence is visible, value is not | “Has delivery deadline” without the date |
redacted |
Field is not visible at this phase | Scout preferences, Beacon margin, identity |
aggregate |
Statistical aggregate across multiple values | “Average offer price” without individual prices |
When Core routes an interpreted request to Beacons (Section 6 → Section 7), it applies the profile’s disclosure schedule to produce a projected request. The projection is a subset of the full interpretation.
disclosure:
beacon_sees_at_discovery:
category: "full" # Beacon needs category to determine relevance
hard_constraints: "full" # Beacon needs constraints to determine feasibility
soft_preferences: "presence" # Beacon knows preferences exist, not specifics
budget:
type: "range" # Range, not exact — prevents price discrimination
range_width: 0.30 # ±15% of actual (e.g., $300 budget → "$255–$345")
delivery_region: "full" # Beacon needs region for logistics
delivery_deadline: "full" # Beacon needs deadline for feasibility
natural_language_context: "redacted" # Never forwarded — Core extracts structured fields
scout_identity: "redacted" # Hidden until commitment (existing protocol rule)
session_history: "redacted" # No cross-session profiling
scout_sees_at_offers:
offer_price: "full" # Scout needs price to decide
product_attributes: "full" # Scout needs product details
beacon_reputation: "full" # Scout needs trust signal
beacon_identity: "redacted" # Hidden until commitment
beacon_margin: "redacted" # Never visible to Scout
beacon_risk_score: "range" # "Low risk" / "Moderate risk", not 0.23
other_offer_count: "aggregate" # "8 offers received", not individual details
A profile defines how disclosure changes across phases. The monotonic disclosure principle (Section 2.4) ensures that fields can only become more visible as commitment increases.
disclosure_progression:
budget:
P2_discovery: "range" # Beacon sees range
P3_offers: "range" # Still range
P4_commitment: "full" # Exact budget visible after commitment
soft_preferences:
P2_discovery: "presence" # Beacon knows they exist
P3_offers: "presence" # Still presence only
P4_commitment: "full" # Preferences visible for fulfillment
beacon_identity:
P3_offers: "redacted" # Scout doesn't know who's offering
P4_commitment: "full" # Identity revealed at commitment
The disclosure model addresses the three leakage risks identified in the protocol review:
The commitment taxonomy governs how participants move from exploration to binding obligation. The protocol defines the possible commitment states and transition mechanics. The profile determines which states are required, what constitutes sufficient commitment at each transition, and what withdrawal rights exist.
The protocol supports five commitment states, ordered by increasing obligation:
| State | Meaning | Obligation | Analogue |
|---|---|---|---|
indicative |
Interest expressed, no obligation | None. Either party can withdraw. | IOI (Indication of Interest) |
qualified |
Interest validated against constraints | Minimal. Scout confirms seriousness. | Qualified lead |
firm |
Terms agreed, pending execution | Conditional. Withdrawal carries reputation cost. | Firm quote / executable order |
binding |
Commitment executed, transaction created | Full. Protocol-enforced obligations apply. | Trade execution |
settled |
Financial obligations completed | Terminal. Dispute window may still be open. | Settlement |
Not every market context requires all five states. The profile specifies the minimum path:
Retail Consumer Profile:
indicative → binding → settled
A consumer browses (indicative), commits (binding), transaction settles. No intermediate qualification step. The firm state is skipped because retail offers have fixed terms — there is nothing to negotiate between expressing interest and committing.
B2B Procurement Profile:
indicative → qualified → firm → binding → settled
A procurement agent expresses interest (indicative), validates budget authority and business rules (qualified), negotiates terms and receives a firm quote (firm), executes the commitment (binding), and settles per negotiated terms (settled). Every state is meaningful because B2B transactions involve authority checks, term negotiation, and approval workflows.
Digital Goods Profile:
indicative → binding → settled
Same as retail, but with instant settlement (settled follows binding atomically). No dispute window hold for pure digital delivery.
Services Profile:
indicative → qualified → firm → binding → settled
Similar to B2B. The qualified state validates service availability and scheduling. The firm state confirms scope and pricing. Milestone-based settlement may span days or weeks.
Each transition has protocol-defined mechanics and profile-defined conditions:
| Transition | Protocol mechanic | Profile condition (examples) |
|---|---|---|
indicative → qualified |
Scout confirms intent is genuine | Min trust level met, budget authority confirmed |
qualified → firm |
Terms negotiated, both parties agree | Offer negotiation complete (Section 4.4.2), business rules pass |
firm → binding |
POST /commit executed |
Payment authorized, clearing gate passed (Section 10.2.1) |
binding → settled |
Settlement confirmed by rail | Settlement finality confirmed, reserve margin held |
Profiles define what happens when a participant withdraws at each state:
commitment:
withdrawal:
from_indicative:
scout: "free" # No cost — this is browsing
beacon: "free" # No cost — offer can be withdrawn
from_qualified:
scout: "reputation_signal" # Recorded but no penalty
beacon: "reputation_signal" # Recorded but no penalty
from_firm:
scout: "reputation_cost" # Meaningful reputation degradation
beacon: "reputation_cost" # Meaningful reputation degradation
from_binding:
scout: "financial_penalty" # Cancellation fee or forfeited deposit
beacon: "financial_penalty" # Breach penalty from reserve
Risk configuration parameterizes the clearinghouse risk engine (Section 10.7) for different market contexts. The risk framework (bilateral assessment, margin calculation, enforcement tiers) is protocol-invariant. The parameters are profile-specific.
risk:
# Risk scoring weights (must sum to 1.0)
composite_weights:
beacon_risk: 0.40 # Seller reliability
scout_risk: 0.25 # Buyer reliability
transaction_risk: 0.35 # Transaction characteristics
# Risk margin bounds
margin:
floor_percentage: 0.02 # Minimum 2% margin on any transaction
ceiling_percentage: 0.25 # Maximum 25% — above this, transaction is declined
consent_tier_multipliers: # From Section 3.3.6
explicit: 1.0
policy: 1.2
delegated: 1.5
# Reputation decay
reputation:
half_life_days: 180 # Reputation signal loses 50% weight after 180 days
min_history_for_full_score: 20 # Minimum transactions for reputation to reach full confidence
new_participant_default: 0.50 # Default risk score for new participants (moderate)
# CWR risk adjustment (Section 9.1)
cwr_risk:
risk_weight: 0.30 # Default weight for risk adjustment
risk_weight_bounds: [0.10, 0.50]
# Enforcement thresholds (Section 3.2.8)
enforcement:
elevated_threshold: 0.35 # Risk score triggering elevated monitoring
restricted_threshold: 0.55 # Risk score triggering transaction limits
blocked_threshold: 0.75 # Risk score triggering clearing block
suspended_threshold: 0.90 # Risk score triggering full suspension
review_period_days: 30 # Days before enforcement tier is reviewed
| Parameter | Retail | B2B | Digital Goods | Services |
|---|---|---|---|---|
| Margin floor | 2% | 1% (lower per-txn, higher volume) | 5% (higher chargeback rate) | 3% |
| Margin ceiling | 25% | 15% (established counterparties) | 30% | 20% |
| New participant default | 0.50 | 0.60 (higher bar for B2B) | 0.50 | 0.55 |
| Reputation half-life | 180 days | 365 days (longer relationships) | 90 days (fast-moving) | 180 days |
| Enforcement → restricted | 0.55 | 0.65 (more tolerance for established) | 0.45 (less tolerance) | 0.55 |
Schema overlays extend the canonical core fields (Session, Offer, Transaction) with domain-specific attributes without breaking interoperability.
┌─────────────────────────────────┐
│ Canonical Core Fields │ ← Protocol-defined, universal
│ (product, pricing, availability│
│ delivery, constraints) │
├─────────────────────────────────┤
│ Domain Overlay │ ← Profile-defined, domain-specific
│ (material specs, certifications│
│ carbon metrics, service SLAs) │
└─────────────────────────────────┘
Canonical core fields are defined in the protocol specification (Appendix A). Every implementation must support them. They are sufficient for basic commerce (product, price, availability, delivery).
Domain overlays are registered per profile and extend structured_attributes with typed, validated fields. An overlay is a JSON Schema document that augments the core schema.
schema:
overlay_id: "retail.electronics.v1"
extends: "offer.product.structured_attributes"
fields:
warranty_months:
type: "integer"
minimum: 0
constraint_eligible: true # Can be used as a hard constraint
energy_rating:
type: "string"
enum: ["A+++", "A++", "A+", "A", "B", "C", "D"]
constraint_eligible: true
brand:
type: "string"
constraint_eligible: true
model_year:
type: "integer"
constraint_eligible: false # Ranking signal only
required: ["warranty_months"] # Minimum fields Beacons must populate
GET /v1/profiles/{profile_id}/schema-overlays. Beacons declare which overlays they support at registration.The identity dimension governs what trust credentials are required for participation in a given market context. Each profile references a Trust Framework (PROTOCOL_SPECIFICATION.md Section 3.1.4) and adds per-action minimum trust levels.
Configuration:
identity:
trust_framework_id: "tf_01HXYZ..."
minimum_trust_levels:
session_creation: "self_declared"
beacon_qualification: "domain_verified"
offer_submission: "domain_verified"
commitment: "self_declared"
commitment_above_threshold: "domain_verified"
commitment_threshold_amount: 1000.00
clearinghouse_participation: "entity_verified"
settlement_above_threshold: "kyc_verified"
settlement_threshold_amount: 50000.00
preferred_credential_formats: []
issuer_restrictions:
blocked_issuers: []
required_issuer_jurisdictions: null
Per-profile trust requirements:
| Profile | Browse | Beacon Qualification | Commitment | Clearing |
|---|---|---|---|---|
| Retail | L0 | L1 (domain) | L0 < $1K, L1 above | L2 |
| B2B Trade | L1 | L2 (entity) | L2 | L2, L3 > $50K |
| Digital Goods | L0 | L1 (domain) | L0 | L2 |
| Services | L0 | L2 (entity) | L1 at qualified |
L2 |
Design principle: AURA is a relying party, not an identity verifier (DEC-049). Principals establish trust by presenting externally-issued credentials. The Trust Framework maps credentials to trust levels. The Market Profile sets the minimum trust levels per action. AURA never performs identity verification — it consumes credentials and enforces trust thresholds.
Trust Framework selection: Different Market Profiles MAY reference different Trust Frameworks. A regulated B2B market might use a Trust Framework that only trusts vLEI and Open Banking credentials from EU-domiciled issuers. A retail market might accept a broader set of issuers.
A Market Profile is a JSON document with the following structure:
{
"profile_id": "prf_retail_consumer_v1",
"profile_version": "1.0.0",
"display_name": "Retail Consumer Marketplace",
"description": "Consumer-facing retail commerce with zero-cost Scout entry, staged disclosure, and real-time settlement",
"market_context": "retail",
"participation": { },
"disclosure": { },
"commitment": { },
"risk": { },
"schema": { },
"governance": {
"owner": "core_operator",
"change_notice_days": 30,
"participant_consent_required": false,
"effective_date": "2026-07-01T00:00:00Z"
},
"metadata": {
"created_at": "2026-04-13T00:00:00Z",
"created_by": "AURA Labs",
"spec_version": "2.0.0",
"references": ["DEC-044"]
}
}
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ draft │────>│ published │────>│ active │────>│ deprecated│
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │
│ (notice │ (sunset
│ period) │ period)
▼ ▼
┌──────────┐ ┌──────────┐
│ revised │ │ sunset │
└──────────┘ └──────────┘
Agents discover available profiles via:
GET /v1/profiles
Response:
{
"profiles": [
{
"profile_id": "prf_retail_consumer_v1",
"display_name": "Retail Consumer Marketplace",
"market_context": "retail",
"status": "active",
"version": "1.0.0",
"links": {
"self": "/v1/profiles/prf_retail_consumer_v1",
"schema_overlays": "/v1/profiles/prf_retail_consumer_v1/schema-overlays",
"participation": "/v1/profiles/prf_retail_consumer_v1/participation",
"disclosure": "/v1/profiles/prf_retail_consumer_v1/disclosure"
}
}
]
}
Each profile dimension is independently retrievable. An agent building a Scout integration only needs participation and disclosure. An agent building risk tooling only needs risk configuration.
When a session is created, it is bound to the active profile:
{
"intent": "I need wireless headphones for my train commute",
"constraints": { "maxBudget": 400 },
"profile_id": "prf_retail_consumer_v1"
}
If profile_id is omitted, the Core instance’s default profile applies. The session record stores the profile version at creation time — if the profile is revised mid-session, the session completes under the original version.
The default profile for consumer-facing marketplaces.
Design priorities: Low friction for Scouts, consumer protection, real-time settlement, moderate risk tolerance.
| Dimension | Configuration |
|---|---|
| Participation | Scout: zero-cost session creation, rate-limited (20/hr). Beacon: quality bond ($500), rate-limited offers. No buyer fees. Clearing fee 2.5% on Beacon. |
| Disclosure | Budget as ±15% range. Soft preferences as presence only. Natural language redacted. Beacon identity redacted until commitment. Scout identity redacted until commitment. |
| Commitment | indicative → binding → settled. No intermediate qualification. Single commit action. Free withdrawal from indicative. |
| Risk | Margin floor 2%, ceiling 25%. 180-day reputation half-life. New participant default 0.50. Consumer dispute filing: zero cost. |
| Schema | Core fields only. Domain overlays optional (electronics, fashion, home goods). |
For enterprise procurement and supply chain commerce.
Design priorities: Authority verification, term negotiation, credit management, longer settlement cycles.
| Dimension | Configuration |
|---|---|
| Participation | Scout: compute-credit model (subscription). Beacon: annual listing fee + quality bond. Per-transaction clearing fee 1.5%. |
| Disclosure | Budget as ±10% range (tighter for B2B — procurement budgets are more structured). Specifications at full disclosure (Beacons need detail for accurate quoting). Soft preferences as presence only. Company identity redacted until firm state. |
| Commitment | indicative → qualified → firm → binding → settled. Authority validation at qualified. Term negotiation at firm. Settlement per negotiated terms (Net 30/60). |
| Risk | Margin floor 1%, ceiling 15%. 365-day reputation half-life. Entity verification (entity_verified) required. Trade credit scoring integrated. |
| Schema | Core fields + procurement overlay (material specs, certifications, compliance requirements, minimum order quantity, bulk pricing tiers). |
For software, licenses, digital content, and API access.
Design priorities: Instant fulfillment, atomic settlement, higher fraud risk tolerance, limited return rights.
| Dimension | Configuration |
|---|---|
| Participation | Scout: zero-cost, rate-limited. Beacon: quality bond ($250). Clearing fee 3% (higher fraud rate). |
| Disclosure | Full constraint disclosure (digital goods have less price discrimination surface). Beacon identity visible at offers (brand matters for software trust). |
| Commitment | indicative → binding → settled (atomic). No dispute window hold for irrevocable digital delivery. |
| Risk | Margin floor 5%, ceiling 30%. 90-day reputation half-life (market moves fast). Elevated chargeback monitoring. |
| Schema | Core fields + digital goods overlay (license type, platform compatibility, version, update policy, API rate limits). |
For professional services, consulting, freelance, and time-based commerce.
Design priorities: Scope definition, milestone-based commitment, scheduling, longer fulfillment cycles.
| Dimension | Configuration |
|---|---|
| Participation | Scout: zero-cost for discovery, staking deposit at firm state. Beacon: portfolio bond + per-engagement clearing fee 2%. |
| Disclosure | Requirements at full disclosure (service providers need complete scope). Budget as range. Timeline constraints at full. Identity revealed at qualified (services are relationship-based). |
| Commitment | indicative → qualified → firm → binding → settled. Milestone-based settlement. Partial withdrawal permitted before milestone completion. |
| Risk | Margin floor 3%, ceiling 20%. 180-day reputation half-life. Milestone-linked risk release (margin decreases as milestones are delivered). |
| Schema | Core fields + services overlay (scope of work, deliverables, timeline, hourly/fixed pricing, revision policy, SLA terms). |
The Market Profile architecture requires the following protocol specification changes:
| Section | Change | Type |
|---|---|---|
| 4.1 | New identifier prefix: prf_ for profile IDs |
Additive |
| 5.1 | profile_id field on session creation request |
Additive (optional, defaults to deployment default) |
| 6.2 | Interpreted request projection applies disclosure schedule | Modification (formalizes existing behaviour) |
| 9.1.1 | Business rule pre-filtering respects profile-level rules | Modification (extends existing mechanic) |
| 14 | Profile discovery and inspection endpoints | Additive |
| 15 | Profile configuration in implementation checklist | Additive |
| Appendix A | Profile JSON schema (A.6) | Additive |
Backward compatibility: All changes are additive or formalize existing behaviour. No breaking changes.
The clearinghouse (CLEARINGHOUSE.md) already operates with several profile-compatible parameters:
| Clearinghouse concept | Profile dimension | Migration |
|---|---|---|
| Risk margin floor/ceiling | risk.margin |
Move from deployment config to profile |
| Consent tier multipliers | risk.margin.consent_tier_multipliers |
Already in spec; profile makes it inspectable |
| Enforcement thresholds | risk.enforcement |
Move from deployment config to profile |
| Payment method preferences | participation.clearing |
Profile declares which rails are available |
| Dispute window minimums | risk.dispute |
Profile sets the minimum; protocol floor (7 days) remains |
The Market Profile architecture is the implementation of concepts described in MARKET_ECONOMICS.md:
| Economics concept | Profile realization |
|---|---|
| “Make defection unprofitable” (Principle 1) | Participation costs at each evaluation point |
| “Constraints are economic signals” (Principle 2) | Disclosure tiers determine which constraints are visible when |
| “Privacy creates fairness” (Principle 4) | Staged disclosure with monotonic progression |
| “Market-specific profiles” (Section 10) | The profile system itself |
| Qualification thresholds (Section 7) | Participation dimension: Beacon qualification costs |
| Information probing prevention (Section 4.2) | Disclosure dimension: budget ranges, preference redaction |
| Strategic non-commitment prevention (Section 4.3) | Commitment dimension: withdrawal rules with escalating cost |
| Reputation decay (Section 7) | Risk dimension: configurable half-life |
New entry for COMPONENT_REGISTRY.md:
Market Profile Engine
Sub-components:
- Profile Registry (CRUD, lifecycle management)
- Disclosure Projector (applies disclosure schedule to interpreted requests and offer responses)
- Participation Cost Evaluator (evaluates cost rules at each evaluation point)
- Commitment State Validator (enforces required commitment path per profile)
- Schema Overlay Registry (manages domain-specific schema extensions)
Dependencies: CLEARINGHOUSE.md (risk parameters), PROTOCOL_SPECIFICATION.md (state machine)
Priority: HIGH
Status: Architecture Designed
Who creates profiles? Who approves changes? What happens when participants disagree with a profile revision? These are governance questions, not architecture questions. The profile structure supports governance (change notice periods, effective dates, participant inspection) but does not prescribe a governance model.
A Beacon registered under a B2B profile and a Scout operating under a retail profile cannot currently transact. Cross-profile matching requires either:
Both are deferred. Initial deployment assumes a single active profile per Core instance.
Profiles are transparent — agents can read all parameters. A sophisticated agent might choose profiles strategically (e.g., using a retail profile for B2B-scale purchases to avoid qualification requirements). Mitigation: profile assignment can be validated against principal trust level and transaction patterns. A principal executing B2B-scale transactions under a retail profile triggers enforcement review.
Profiles are static for the duration of a session. Real-time parameter adjustment (e.g., tightening risk margins during a market event) is not supported. This is intentional — participants must be able to rely on stable rules during a session. Profile revisions apply only to new sessions after the notice period.
MARKET_ECONOMICS.md Section 10 identified the FIX protocol trajectory as the likely evolution path. Market Profiles make this analogy concrete:
| FIX concept | AURA Market Profile equivalent |
|---|---|
| Venue rules (lot sizes, tick sizes, order types) | Profile parameters (costs, disclosure tiers, commitment states) |
| Session-level protocol (logon, heartbeat, message sequencing) | Protocol-invariant layer (state machine, crypto, clearing lifecycle) |
| Application-level messages (order types vary by asset class) | Schema overlays (domain-specific attributes) |
| Regulatory compliance (MiFID, Reg NMS) | Profile constraints (mandatory minimums, jurisdiction rules) |
| Market data levels (L1 top of book, L2 depth, L3 full book) | Disclosure tiers (redacted → presence → range → full) |
The key lesson from FIX: the protocol survived 30 years because it separated the invariant (message transport, session management, sequencing) from the variant (venue-specific rules, asset-class-specific messages). AURA’s Market Profiles apply the same separation.
| Date | Change |
|---|---|
| 2026-04-13 | v1.0 Initial architecture document. Five profile dimensions (participation, disclosure, commitment, risk, schema), four reference profiles (retail, B2B, digital goods, services), integration mapping to Protocol Specification v2.0, CLEARINGHOUSE.md, and MARKET_ECONOMICS.md. Driven by DEC-044. |
| Version | Date | Changes |
|---|---|---|
| 1.1 | 2026-04-14 | Added version header, protocol reference to v2.2. Added identity dimension (Section 3.6, DEC-049). Updated verification_level to trust_level. |
| 1.0 | 2026-04-13 | Initial market profiles architecture — 5 dimensions, 4 reference profiles, FIX analogy. DEC-044. |