OFM content studio and generative-media domain

Date: 2026-08-29 Status: full research campaign complete; final callback delivered Owner: OFM-CONTENT

Executive decision (provisional)

HALO should own the creator-safe content control plane: creator boundaries and consent, briefs, work-item state, asset provenance, approvals, rights/expiry, delivery evidence, and the links back to creator/custom/request truth. It should integrate specialist media review, DAM/MAM, generative-media, and publishing systems where those systems are materially better at bytes, codecs, frame review, or platform delivery. Google Drive can remain a human-friendly byte/archive surface during migration, but its folders and filenames should not be the authoritative workflow state.

Fact from the read-only clone: HALO already has useful foundations—creator/model profiles and content limits, model announcements and a calendar, a public creator upload handoff, a Google Drive index with unused/used tracking, custom-request metadata, and an ElevenLabs voice-clone/generation queue. Inference: those foundations are not yet a content studio because no single HALO state machine connects idea → brief → versioned review → creator approval → publishing/retry → performance feedback → rights-aware reuse. The full campaign below tests which parts to build and which to buy.

Persona and authority map

This is the target authority boundary for the complete operating loop. The “current HALO evidence” column records what the clone actually exposes; it is not a claim that the target control is already implemented.

End-to-end operating journey

The authoritative record named in each step is the proposed target record. Current HALO coverage is called out separately below so the journey does not collapse into today’s screens.

1. Enter with an active creator and a rights boundary. The creator is onboarded and

identity/contract/consent evidence is available; content permissions, exclusions, likeness/voice scope, geography, channel, expiry, and revocation are explicit. If a boundary is missing or expired, the work item starts blocked, not “approved by default.” Authority: HALO creator + rights/consent record.

1. Create an idea, request, or campaign brief. A manager, producer, creator, or a

chatter-linked custom request creates an idempotent work item with objective, audience, deliverables, content class, due date, creator, rights scope, safety notes, and target channel. Authority: HALO brief/work-item record; a custom request remains the commercial source of truth for its promise and price.

1. Resolve the brief into a script and shot list. The producer versions the copy,

references, wardrobe/prop constraints, required framing, accessibility/localization, and expected derivatives. Creator questions and boundary changes become explicit decisions on the brief rather than disappearing into chat. Authority: versioned brief.

1. Schedule people and capture. The manager schedules a shoot or creator submission;

the creator or capture team records the source and uploads it. The upload is quarantined until type, size, malware, identity, rights scope, and destination are checked. A Drive outage or upload retry must not create a second logical asset. Authority: capture/upload receipt and immutable source hash. Current /upload/:id is only a thin file handoff.

1. Ingest and normalize. The ingest worker records source URI, checksum, media kind,

dimensions, duration, capture/modified timestamps, uploader, import time, and parent work item. It strips or quarantines sensitive EXIF/GPS data according to policy, creates safe previews, and retains the original only under the appropriate access boundary. Authority: asset/provenance record; bytes may be in a DAM, object store, or Drive.

1. Classify, deduplicate, and link. Taxonomy is a controlled vocabulary (creator,

content class, channel, campaign, request, safety/rights labels). Exact hashes catch duplicates; perceptual similarity is a review signal, never an automatic deletion verdict. A reused source links to its existing lineage. Authority: asset identity and lineage graph.

1. Edit into immutable versions. Editors create derivatives with parent pointers,

tool/provider versions, prompts or source references where applicable, and a machine check result. Replacing a file creates a new version; it does not overwrite the approved history. Authority: version record and its source lineage.

1. Run technical and human review. Automated checks can flag dimensions, audio,

watermark, duplicate, unsafe prompt/output, missing consent, or rights expiry. Reviewers attach frame/timecode comments and resolve them against a specific version. A creator approval and the agency/manager operational approval are separate decisions. Authority: review threads plus explicit approval records. Failure state: changes_requested, blocked, or expired, never an implicit pass.

1. Package and deliver. Only an approved version produces a delivery package with the

target channel, caption/copy, price or request link where relevant, disclosure/watermark requirements, and idempotency key. The publisher adapter attempts delivery and records attempts, response, retryability, and human takeover. Platform publication is authoritative for “live”; HALO is authoritative for why this version was allowed. Failure state: retryable, needs_reauth, rejected_by_platform, takedown_pending, or manual_hold.

1. Connect the result back to work and revenue. The published asset, custom request,

platform post/content ID, campaign, and approved creator scope stay linked. Performance feedback records observations and source windows without rewriting the original asset or approval. Chatter operators see released content and request links, not hidden rights or raw private material. Authority: platform receipt for delivery and HALO link/attribution record for agency operations.

1. Reuse safely. A reuse creates a new planned use with the old asset lineage, a fresh

rights-scope check, channel restrictions, and (if needed) new creator approval. “Used” means consumed in one workflow, not “safe everywhere.” Current Drive’s USED : POSTED folder is a useful operational signal but too coarse for this rule.

1. Expire, revoke, archive, and exit. Expiry or revocation places affected uses on

hold, identifies published copies and derivatives, records takedown/export actions, and preserves the audit trail. On staff turnover or creator departure, export a manifest containing asset IDs, hashes, lineage, approvals, rights scope, delivery receipts, linked requests, and retention decisions; revoke access and provider tokens. Authority: HALO rights/audit/export records, with storage deletion performed only after policy and legal holds are satisfied.

Feature and sub-app tree

Content operating system
├── Creator control and rights
│   ├── creator boundaries, consent grants, likeness/voice scopes, expiry/revocation
│   ├── creator portal: briefs, upload receipt, review, approve/reject, export
│   └── access, geographic restrictions, redaction, audit and wellbeing safeguards
├── Planning and intake
│   ├── ideas, campaigns, recurring content plans, briefs, scripts, shot lists
│   ├── creator availability / shoot schedule
│   ├── chatter-linked custom requests and promised deliverables
│   └── dependencies, assignments, SLAs, holds and exception queues
├── Production
│   ├── capture/upload quarantine and resumable ingest
│   ├── metadata normalization, taxonomy, hash/dedup and EXIF/privacy policy
│   ├── asset lineage, versions, derivatives and edit-tool/provider receipts
│   └── storage adapters: Drive, object storage, DAM/MAM
├── Review and approval
│   ├── frame/timecode/image-region review threads
│   ├── technical/safety/rights checks
│   ├── creator approval separate from manager/agency approval
│   └── immutable decision history, changes requested and escalation
├── Delivery and publishing
│   ├── channel-specific packaging, captions, pricing and disclosure
│   ├── human-approved publish queue, idempotency and retry/backoff
│   ├── platform receipts, re-auth/hold/takedown states
│   └── approved asset links for chatter/custom fulfillment
├── AI media studio
│   ├── prompt/reference registry and consent-scoped jobs
│   ├── image, video, voice and audio generation adapters
│   ├── provenance/watermark/content credentials and safety evaluation
│   └── human review, rollback, provider deletion and revocation handling
├── Feedback and reuse
│   ├── performance observations linked to post/asset/version
│   ├── reuse requests with fresh rights checks
│   ├── archive, retention, export and offboarding manifests
│   └── creator-facing progress and transparent status
└── Shared primitives
    ├── stable IDs, event timestamps, idempotency, audit and typed links
    ├── fine-grained RBAC and break-glass access
    ├── secrets/token vault and provider scopes
    └── Buzz notifications, assignments and agent tools via server-side adapter

Current HALO coverage and gaps (read-only map)

Claimed existing model app: evidence status

Observed fact: the known route map contains a public creator upload screen, tokenized onboarding and contract-signing routes, and internal Model Profile surfaces. Observed fact: the bounded internal note says the route map alone cannot prove or disprove a dedicated model-facing app. Conclusion: this report treats /upload/:id, onboarding, signing, and Model Profile as the actual HALO surfaces currently evidenced; it does not label a complete creator portal “missing” until the repository/deployment/product evidence search is complete. A separate creator app, route hidden behind auth, or another deployment would change the map and will be recorded if found.

Initial search vocabulary and coverage receipt (urgent milestone)

The search must be intent-led rather than “OnlyFans CRM” led. Candidate families and query terms are:

• Planning / production tracking: media production management, content operations,

VFX production tracking, animation pipeline, game art pipeline, shot list, asset task, editorial workflow, approval gates, change requests, custom content fulfillment.

• DAM / MAM / provenance: digital asset management, media asset management, asset

lineage, derivative graph, checksum/dedup, perceptual hash, EXIF/GPS scrubbing, archive manifest, rights-managed media, expiry/revocation, content credentials, C2PA.

• Review: frame-accurate video review, timecode comments, image annotation, version

compare, review-and-approve, client proofing, human-in-the-loop media QA.

• Publishing / feedback: social publishing API, content calendar, publish retry,

idempotent delivery, platform receipt, takedown workflow, post-level analytics, asset performance feedback.

• Creator / talent workflows: creator portal, model release, likeness consent, talent

rights, influencer content operations, casting/ATS handoff, client approval portal.

• Generative media: voice cloning consent, likeness management, synthetic media safety,

AI image/video generation workflow, prompt registry, model provenance, watermarking, human approval, provider deletion/revocation.

• Adjacent operator language: “content backlog,” “unused content,” “content day,”

“custom request fulfillment,” “approval bottleneck,” “content vault,” “content manager,” “churn from posting,” “faceless/AI creator,” “voice note workflow,” and creator complaints about lost files, missed deadlines, leaked metadata, or unapproved reuse.

Receipt at urgent boundary: HALO read-only map and the required feature/journey tree are written above. The full local-corpus, GitHub, live-product, and operator campaign is completed below; promoted candidates and rankings are evidence-scoped, not inferred from the initial vocabulary alone.

Evidence labels and decision rule

This report uses the following labels so a polished product page, a README, and a checked runtime observation do not collapse into the same kind of evidence:

• [FACT] observed directly in the HALO clone, the protected Oracle source, a read-only

gh api response, a first-party product/API document, or an identified academic paper.

• [VENDOR CLAIM] a supplier's own feature, maturity, outcome, or security statement. It

is useful for a trial checklist, not proof that HALO's adult-content workflow is supported.

• [OPERATOR SELF-REPORT] a practitioner post, agency page, or workflow guide describing

practice. It is a vocabulary and hypothesis source unless independently reproduced.

• [INFERENCE] a conclusion drawn from more than one fact. It is explicitly marked and is

not presented as a current system capability.

• [PROPOSAL] a target HALO/Buzz design or a proof plan. Proposals never change authority

boundaries by implication.

Stars, list placement, freshness, and search rank are discovery signals only. A high-star repository is not automatically safer, more mature, adult-policy-compatible, or licensable.

Internal prior art and crossover

HALO model-facing evidence found

The “existing model-facing app” request changes the correct question. The repository and its deployed bundle do contain real creator-facing surfaces; the evidence does not yet prove a separate, complete model content-studio application.

[FACT] Live deployment check. On 2026-08-29, read-only GET requests to the public HALO deployment returned 200 for the root, /upload/test, /onboarding-form/test, and /contracts/sign/test. The root HTML identified HALO Creator Management and loaded /assets/index-LD33amar.js. A read-only scan of that deployed bundle contained the route strings for /upload/:id, /onboarding-form/:token, /contracts/sign/:token, the Complete Your Creator Profile onboarding copy, and the AI-voice/upload code. SPA fallback means the 200 response alone is not route-level proof; the bundle strings plus the local source are the stronger evidence. No credentials, mutation, or live account action was used.

[CONCLUSION] HALO has an actual model-facing route set: onboarding, signing, and upload, plus a model-self profile path and staff-facing profile/voice surfaces. [UNRESOLVED CLAIM] The existence, URL, auth boundary, or current build identity of a dedicated model content app beyond these surfaces is still unverified. Therefore this report does not declare the dedicated app absent; it records the exact HALO evidence found and keeps the discovery/proof request open.

Protected Oracle prior art, verified at the routed read-only source

The Oracle repository was used only as protected read-only prior art. Its AGENTS.md and CLAUDE.md route the current Mac worker to Rust/Tauri, keep Electron scoped to the VPS engine and browser shell, and prohibit treating labels or historical proofs as current runtime procedure. No Oracle launch, credential use, live action, or edit was performed.

Oracle crossover: transferable and non-transferable

[FACT / BOUNDARY] Oracle's Tasks/Rewards-like progress, live cockpit, tips, overlays, and account-safety controls are not an OnlyFans messaging surface and do not solve creator consent, content rights, or asset lineage. [INFERENCE] The strongest crossover is the control-plane discipline and one-next-action UX; the weakest crossover is direct feature reuse.

What are we still missing?

The precise gap statement

[CONCLUSION] We are not missing “a model app” in the broad sense: HALO already exposes model-facing onboarding, contract signing, and upload, and a deployed bundle contains those routes. We are missing evidence and implementation of the connected, rights-aware content loop that turns those surfaces into a creator-safe operating system.

First-principles test

The content system is correct only if an authorized replacement operator can answer these five questions without opening raw private material or asking a side channel:

1. What exactly is this asset/version, and where did it come from?
2. What did this creator and any other participant consent to, for which channel and until when?
3. Who approved this exact version, and what changed after approval?
4. Which delivery attempt published it, to which account, and can the platform receipt be found?
5. If consent expires or is revoked, which derivatives and published uses are held, removed,

exported, or legally retained?

[INFERENCE] HALO's present profile, Drive, customs, upload, and voice surfaces answer parts of question 1 and provide inputs to questions 2–4, but not the complete chain. That is why the right next product proof is a connected synthetic fixture loop, not a larger navigation menu.

Adjacent-market evidence

Public/private/GitHub/operator reasoning

[PUBLIC VENDOR CLAIM] OFMLab describes a Drive-centered OFM agency loop with creator Today views, review inbox, approve/reject, recurring tasks, XP, and per-creator dashboards (public product page ↗). Empire of Agency describes a private CRM joining creators, managers, chatters, content, conversations, tasks, approvals, and reporting (public agency page ↗). AfterDark LAB presents an agency OS with content/fan/revenue operations (public product page ↗). These pages are valuable because they use domain vocabulary—Today, assignments, approval, publish, next decision—but they expose no independent tenant walkthrough, source code, audit export, or creator-consent proof in this campaign. Treat them as vendor/marketing claims until verified.

[PUBLIC OPERATOR/EDITORIAL CLAIM] A public OFM SOP guide describes scheduling, creator confirmation, briefs, raw submission, editing queue, technical/brand/compliance/creator gates, publishing confirmations, missed-window escalation, and rogue-publish checks (guide ↗). It is useful for a candidate state vocabulary, but its conversion benchmarks and timing targets are not accepted as HALO metrics.

[OPERATOR SELF-REPORT] An agency operator post says shared Drive comments, Notion, email, and generic project tools caused wrong-version confusion, while one review link, staged approval, separate client/internal views, named ownership, and visible stuck states helped (r/agency workflow post ↗). It is one self-report and vendor-adjacent, not a population estimate. Separate OnlyFans creator posts discuss batching shoots, scheduling, reuse, final upload QC, and the danger of selecting the wrong file; these are directional operator signals, not validated product requirements.

[ACADEMIC FACT] A qualitative study of 22 U.S. OnlyFans creators identifies boundary setting, privacy, and content archives as important platform affordances (Hamilton et al., 2022 ↗). A later USENIX Security study of 43 creators documents content leakage, stigma, platform precarity, watermarks, identity separation, and proactive safety practices (Soneji et al., USENIX Security 2024 ↗). These support the design priority of creator control and privacy; they do not prove the exact HALO workflow or a willingness to adopt any vendor.

[INFERENCE] Public information has abundant content-calendar/approval/DAM patterns and abundant AI generation demos, but little independently verifiable public evidence of a single OFM-specific system that joins creator rights, private adult media lineage, two-party approval, platform delivery, and takedown/export. The private-client evidence and direct interviews are therefore the highest-value next research, not another star-count sweep.

Search campaign and coverage receipt

Search date: 2026-08-29. Scope was read-only. No Convex mutation, seed/reset/migration, credential use, protected Oracle launch, commit, push, or deployment was performed.

Local corpus

The queries were intent-led across planning/production tracking, DAM/MAM, review and approval, publishing/retry, creator/talent operations, voice/likeness, provenance/C2PA, and adjacent operator vocabulary. Candidate names were then exact-matched in both databases to prevent a description-only hit from becoming a promoted repo. Selected local signals included:

The corpus was used to generate candidates, not to award adoption rank. The current GitHub screen below is the authority for metadata and license handling.

GitHub search and verification method

Live gh search repos queries covered: digital asset management, video review approval, content operations, social media scheduler, production tracking, creator content, voice cloning consent, and content approval workflow. Search results were noisy—many were portfolio/demo repositories—so the promoted set was screened for a direct match to a content job before verification.

For every GitHub repository linked in this report, gh api repos/OWNER/NAME was run on 2026-08-29 and the following fields were recorded: full_name, html_url, stargazers_count, license.spdx_id, pushed_at, archived, and default_branch. For NOASSERTION, the root tree and license-like files were inspected with gh api; no SPDX label was invented. The individual results are in the verification ledger below.

Live-product and operator search

• Review/DAM: Frame.io V4 help, Autodesk Flow, Iconik, Cloudinary DAM APIs, Filestage,

and Bynder API docs. The search favored first-party docs for capability facts.

• AI/provenance: ElevenLabs voice-cloning/sharing docs and C2PA specification/standard

pages. These establish provider/standard boundaries, not HALO permission.

• OFM/operator: public OFM agency/product pages, the public SOP guide, practitioner posts,

OnlyFans creator discussions, and the 22-/43-creator academic studies. Vendor metrics and conversion claims were excluded from rankings; direct OFM interviews remain open.

• Search tooling note: the configured Perplexity websearch command was unavailable because

OPENROUTER_API_KEY was not present. The built-in web reader and first-party URLs above were used instead. This did not block the required evidence pass.

Ranked full-system and live-product candidates

Rank means fit to the OFM content-control problem, not market size or stars. “Integrate” means sidecar/adaptor evaluation; it never transfers HALO's creator, rights, approval, or audit authority.

Ranked verified GitHub candidates

The table is intentionally conservative. “Study” means extract a data/UX pattern in a clean fixture; “integrate” means a narrowly scoped adaptor after legal/security review; “build” means reimplement the domain contract inside HALO; “reject” means do not make it a dependency for this wave. Metadata is a 2026-08-29 gh api snapshot and may change.

Patterns worth rebuilding in HALO

These are ranked by domain value and safety, not by whether a repo can be copied:

1. One review link per immutable version. The link should show only the approved scope,

exact version, comments, decision state, and expiry; internal notes remain private.

1. Rights-first candidate filtering. Before AI search or sequencing sees an asset, a

deterministic service filters by creator, scope, channel, geography, expiry, revocation, participant releases, and legal hold. AI can interpret the brief only over permitted IDs.

1. A real content state machine. Make changes_requested, creator_approved,

agency_approved, retryable, needs_reauth, takedown_pending, and manual_hold first-class states rather than text labels.

1. Two approvals, one version. Creator/participant consent and agency/compliance release

are separate decisions. Approval locks the package; edits create a new version.

1. One work item, many channel records. Keep one brief and lineage graph, then separate

per-channel copy/media/settings/delivery attempts. A publisher cannot change the source asset or consent record.

1. Content calendar as a projection. A date points at an approved package; it does not

promote raw footage or a draft to ready.

1. Quarantine and provenance on ingest. Hash before dedup, preserve original lineage,

record EXIF/GPS policy, and create safe previews without treating a preview as the source.

1. Creator Today view. Show assigned work, due dates, exact upload/review action, rejected

reason, and next step. Hide credentials, fees, internal notes, and unrelated fan data.

1. Evidence-backed copilot. Offer concise brief summaries, missing-footage explanations,

and next-review prompts with source IDs. A missing candidate must be reported, not invented.

1. Offboarding as a first-class journey. Export IDs/hashes/lineage/approvals/rights and

delivery receipts, revoke access/tokens, enumerate derivatives, and preserve legal holds.

Rejected famous or tempting options

Recommended HALO + Buzz composition

Ownership boundary

[PROPOSAL] Keep HALO as the content control plane and make every sidecar replaceable:

Creator / manager / producer
        │
        ▼
HALO content control plane
  creator + consent + contract scope
  brief/work item + assignments + approvals
  asset/version lineage + rights/expiry/revocation
  delivery attempts + platform receipts + audit/export
        │ typed adapters, stable IDs, idempotency keys
        ├── byte/DAM sidecar (Drive, Cloudinary, Iconik, or object store)
        ├── review sidecar (Frame.io, Filestage, Clapshot, or built review)
        ├── generation provider (ElevenLabs / image / video adapter)
        └── publisher adapter (channel-specific, human-approved)
        │
        ▼
Buzz = coordination/event surface
  assignments, summaries, review links, escalation, callbacks
  no raw authority over creator, rights, source bytes, money, or publish

Buzz remains fixed as block/buzz. It may receive review.requested, approval.recorded, delivery.failed, or rights.expiring events containing stable HALO IDs and a scoped summary. Its server-side adapter may call a bounded HALO tool such as “open this review” or “prepare a retryable delivery,” but it must not mutate a creator boundary or send a platform action from chat alone. The final publish action is a HALO/server-side adapter operation gated by the exact approved version, rights check, account scope, and idempotency key.

Minimal state contracts

[PROPOSAL] Keep work state, rights state, review state, and delivery state orthogonal:

work:    idea → briefed → assigned → capture_due → ingesting → quarantined
         → editing → review → changes_requested → creator_approved
         → agency_approved → ready_to_publish → publishing → published
         → observed → reusable | archived

rights:  pending | active | expiring | expired | revoked | legal_hold
review:  not_started | technical_failed | changes_requested | creator_approved
         | agency_approved | rejected | superseded
delivery: not_ready | queued | attempting | succeeded | retryable
          | needs_reauth | rejected_by_platform | takedown_pending | manual_hold

The transition record must include actor, timestamp, prior/new state, reason, version ID, rights snapshot ID, and correlation/idempotency key. A sidecar callback can advance delivery only after verifying the package and scoped account; it cannot advance creator_approved or agency_approved.

Build/buy/integrate/study/reject ledger

Phased proof plan (synthetic data first)

No real adult media, real creator account, platform login, or Convex mutation is required for the first proof. The following is a future implementation/evaluation plan, not an action run in this campaign.

GitHub verification and license ledger

This is the compact receipt for every GitHub link in this report. Each row was checked with the GitHub REST repository endpoint on 2026-08-29. NOASSERTION means GitHub did not provide an SPDX assertion; the source inspection result is stated separately.

Negative findings and open questions

• Dedicated app: actual HALO model-facing routes are proven; a separate dedicated model

content app/build/auth boundary is still unresolved. Do not close this by saying “no model app exists.”

• Content state machine: no connected idea→brief→version→review→creator approval→agency

approval→publish/retry→performance/reuse chain was evidenced in the HALO route/schema map.

• Rights: current content-limit booleans, contract signing, and profile fields are not a

versioned consent/likeness/voice/channel/expiry/revocation registry.

• Drive: folder/index/USED : POSTED signals are useful migration evidence, not durable

authority for lineage or safe reuse; live Drive operations need hardening.

• Publishing: no HALO content publishing adapter/receipt/retry state was evidenced. A

generic social scheduler cannot fill the rights gap.

• AI media: the ElevenLabs queue is real, but image/video generation, consent-scoped jobs,

provenance, provider deletion, and human release are open.

• Public evidence: vendor pages and community posts provide vocabulary and workflow

hypotheses; vendor metrics are untrusted; direct OFM interviews remain open.

• Platform policy: adult-content storage, AI likeness, privacy, retention, deletion, and

distribution policies must be checked per selected sidecar/provider. No product was promoted on a generic “supports video” claim alone.

• C2PA limit: a valid signed manifest can establish an edit/provenance assertion; it does

not establish consent, contract scope, or permission to publish.

• Buzz limit: Buzz may coordinate and surface evidence-linked decisions; it is not content,

rights, money, credential, or publish authority.

• Oracle limit: the protected Oracle cockpit is validated prior art for one-next-action UX,

event/control-plane discipline, goal/progress honesty, and proof receipts. Streaming, platform chat/tips, OBS/OME, account safety, and live credentials do not transfer.

Final recommendation

[PROPOSAL] Build the smallest HALO-native content control loop around the real surfaces that already exist: tokenized onboarding and contract evidence feed a creator/rights record; the existing upload route becomes a quarantine/intake handoff; customs and calendar become linked work-item inputs; Drive remains a storage adapter; the AI voice queue becomes the first provider job wrapped in consent/provenance gates; and Buzz exposes only typed, scoped coordination.

The first ship bar is not “AI makes content.” It is: a synthetic creator can see one assigned brief, submit one asset, receive a versioned review note, approve/reject the exact version, see the rights state, and produce one idempotent delivery receipt—with every denial, retry, expiry, revocation, and offboarding export provable. Only after that bar passes should HALO decide which specialist DAM/review/publishing provider earns an adapter.